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 ???.

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 1989 Part 3 - Drafting and presentation of International Standards.

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

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

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

ISO/IEC 10646-1:2000 Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane

ISO/IEC 10646-1:2000/Amd 1:2002 Mathematical symbols and other characters

ISO/IEC 10646-2:2001 Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 2: Supplementary Planes

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
Application Entity Title
Protocol Data Unit
Transfer Syntax.

3.2 ACSE Service Definitions

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

Association or Application Association
Association Initiator.

3.3 Presentation Service Definitions

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

Abstract Syntax
Abstract Syntax Name
Presentation Context
Transfer Syntax
Transfer Syntax Name.

3.4 DICOM Introduction and Overview Definitions

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

Information Object

3.5 DICOM Information Object Definitions

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

Information Object Definition (IOD).

3.6 DICOM Service Class Specification Definitions

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

Real-World Activity
Service Class.
Service Class User (SCU)
Service Class Provider (SCP)
Service-Object Pair (SOP) Class
Meta SOP Class.

3.7 DICOM Data Structure and Encoding Definitions

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

DICOM Defined UID
Privately Defined UID
Transfer Syntax: (Standard and Private)
Unique Identifier (UID).

3.8 DICOM Message Exchange Definitions

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

Extended Negotiation
Implementation Class UID.

3.9 DICOM Upper Layer Service Definitions

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

Unique Identifier (UID)
DICOM Upper Layer Service
Presentation Address.

3.10 Media Storage and File Format for Data Interchange

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

File-set
File-set Creator (FSC)
File-set Reader (FSR)
File-set Updater (FSU)
Application Profile

3.11 DICOM Conformance

This Part uses the following definitions:

3.11.1 Conformance Statement

A formal statement associated with a specific implementation of the DICOM Standard. It specifies the Service Classes, Information Objects, Communications Protocols and Media Storage Application Profiles supported by the implementation.

3.11.2 Standard SOP Class

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

3.11.3 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 unfamiliar with the additional Type 3 Attributes would simply ignore them.

3.11.4 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.

3.11.5 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.

3.11.6 Standard Attribute

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

3.11.7 Private Attribute

An Attribute that is not defined in the DICOM Standard.

3.11.8 Standard Application Profile

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

3.11.9 Augmented Application Profile

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

3.11.10 Private Application Profile

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

3.11.11 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.

3.11.12 Transformation of DICOM SR to CDA

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

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
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
WADO-WS: Web Access to DICOM Objects by Web Services (WS*)

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 between the local Application Entities, and whatever remote Application Entities that handle the remote Real-World Activities. An arrow from the local Application Entity to the remote Real-World Activity indicates that an occurrence of the local Real-World Activity will cause the local Application Entity to initiate an association for the purpose of causing the remote Real-World Activity to occur. 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.

Different structures are used for the content of Conformance Statements depending on whether the implementation supports a DICOM network interface, a DICOM Media Storage interface, or a combination thereof. In the latter case, a single Conformance Statement shall be provided that consists of the appropriate sections.

The first part of the conformance statement contains a DICOM Conformance Statement Overview, which is typically a one-page description in the beginning of the document providing a high level description and also listing the Networking and Media Service Classes, including their roles (SCU/SCP, FSC, FSR, etc.).

6.1 Overview of Networking Section for Conformance Statements

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

a functional overview containing the Application Data Flow Diagram that shows all the Application Entities, including any sequencing constraints among them. It also shows how they relate to both local and remote Real World Activities;
a more detailed specification of each Application Entity, listing the SOP Classes supported and outlining the policies with which it initiates or accepts associations;
for each Application Entity and Real-World Activity combination, a description of proposed (for Association Initiation) and acceptable (for Association Acceptance) Presentation Contexts;

Note

A Presentation Context consists of an Abstract Syntax plus a list of acceptable Transfer Syntaxes. The Abstract Syntax identifies one SOP Class or Meta SOP Class (a collection of related SOP Classes identified by a single Abstract Syntax UID). By listing the Application Entities with their proposed and accepted Presentation Contexts, the Conformance Statement is identifying the set of Information Objects and Service Classes that are recognized by this implementation;

for each SOP Class related to an Abstract Syntax, a list of any SOP options supported;
a set of communications protocols that this implementation supports;
a description of any extensions, specializations, and publicly disclosed privatizations in this implementation;
a section describing DICOM related configuration details;
a description of any implementation details that may be related to DICOM conformance or interoperability;
a description of what codes and controlled terminology mechanisms are used.

6.2 Overview of Media Storage Section for Conformance Statements

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

a functional overview containing the Application Data Flow Diagram that shows all the Application Entities, including any sequencing constraints among them. It also shows how they relate to both local and remote Real-World Activities;
a more detailed specification of each Application Entity listing the Media Storage Application Profiles supported (this defines SOP Classes supported and media selected), which outlines the policies with which it creates, reads, or updates File-sets on the media;
a list of optional SOP Classes supported;
for each Media Storage SOP Class related to a media storage Application Profile, a list of any SOP options supported;
for each Media Storage SOP Class related to a media storage Application Profile, a list of optional Transfer Syntaxes supported;
a description of any extensions, specializations, and publicly disclosed privatizations in this implementation such as Augmented or Private Application Profiles;
a section describing DICOM related configuration details;

a description of any implementation details that may be related to DICOM conformance or interoperability;

a description of what codes and controlled terminology mechanisms are used.

7 Conformance Requirements

An implementation claiming DICOM conformance may choose to support one of the following:

network conformance according to Section 7.1 (DICOM Network Conformance Requirements);
media storage conformance according to Section 7.2 (DICOM Media Storage Conformance Requirements);
both of the above.

7.1 DICOM Network Conformance Requirements

An implementation claiming DICOM network conformance shall:

conform to the minimum conformance requirements defined in this section;
provide with the implementation a Conformance Statement structured according to the rules and policies in this Part including Annex A;
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 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.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 with the implementation a Conformance Statement structured according to the rules and policies in this Part including Annex C;
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.

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.

A DICOM Conformance Statement Template (Normative)

This Annex is a template that shall be used to generate a DICOM Conformance Statement. The document is hierarchically structured in three different levels:

A DICOM Conformance Statement Overview, which is typically one page, geared towards people that want to get a quick overview of the functionality and services.
For Networking and Media, the relationship between the AEs, followed by the information for each AE
For the services supported as SCU and SCP all the SOP specific details

Annexes are provided to specify the Object descriptions (IODs), with specifics about the field usage as well as the data dictionaries.

Note

The numbering scheme for numbering paragraphs in this document is to be used as a guideline in preparing the outline of the Conformance Statement. Although strongly encouraged, the Conformance Statement is not required to have exactly the same paragraph numbers because a particular Conformance Statement might have special considerations, which will cause the outline to differ in certain details from the outline of this document. In addition, a vendor might have internal company guidelines prescribing a specific format. Note however, that the overall structure, tables, definition of variables and information such as headers, should be strictly followed.

A.0 Cover Page

A DICOM Conformance Statement may have a cover page, which, if present, shall include:

The commercial name 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

A.1 Conformance Statement Overview

The Overview consist of typically 5-10 lines describing the network services and media storage capabilities supported by the product in layman's terms (i.e., no DICOM acronyms should be used).

A table of Supported Networking DICOM Service (SOP) Classes is provided with roles (User/Provider), organized in 4 categories:

Transfer
Query/Retrieve
Workflow Management
Print Management

The first column shall specify the SOP Classes exactly as named in PS3.6., Registry of DICOM Unique Identifiers. The phrase "and specializations" may be added to indicate support of all specializations negotiated through the SOP Class Common Extended Negotiation. If the implementation supports all SOP Classes of a particular Service Class through SOP Class Common Extended Negotiation, the first column shall specify "All services of the <x> Service Class".

Table A.1-1. Network Services

SOP Classes	User of Service (SCU)	Provider of Service (SCP)
Transfer
CT Image Storage	Yes	No
US Image Storage	Yes	Yes
Query/Retrieve
Patient Root Information Model FIND	Option	No
Notes, Reports, Measurements Transfer
Comprehensive SR, and specializations	No	Yes
…

The services can be specified as a SCU, SCP or as an Option, which means that it is either configurable or that it can be purchased separately.

Note

Verification SCP (C-Echo) is not included in the table above because it is required for any Acceptor of an Association. The Verification SCU details are covered in the details of the conformance statement.

The SOP Classes are categorized as follows:

Table A.1-2. UID Values

UID Value	UID Name	Category
1.2.840.10008.1.20.1	Storage Commitment Push Model SOP Class	Workflow Management
1.2.840.10008.1.40	Procedural Event Logging SOP Class	Workflow Management
1.2.840.10008.1.42	Substance Administration Logging	Workflow Management
1.2.840.10008.3.1.2.3.3	Modality Performed Procedure Step SOP Class	Workflow Management
1.2.840.10008.3.1.2.3.4	Modality Performed Procedure Step Retrieve SOP Class	Workflow Management
1.2.840.10008.3.1.2.3.5	Modality Performed Procedure Step Notification SOP Class	Workflow Management
1.2.840.10008.4.2	Storage Service Class	Transfer
1.2.840.10008.5.1.1.1	Basic Film Session SOP Class	Print Management
1.2.840.10008.5.1.1.2	Basic Film Box SOP Class	Print Management
1.2.840.10008.5.1.1.4	Basic Grayscale Image Box SOP Class	Print Management
1.2.840.10008.5.1.1.4.1	Basic Color Image Box SOP Class	Print Management
1.2.840.10008.5.1.1.9	Basic Grayscale Print Management Meta SOP Class	Print Management
1.2.840.10008.5.1.1.14	Print Job SOP Class	Print Management
1.2.840.10008.5.1.1.15	Basic Annotation Box SOP Class	Print Management
1.2.840.10008.5.1.1.16	Printer SOP Class	Print Management
1.2.840.10008.5.1.1.16.376	Printer Configuration Retrieval SOP Class	Print Management
1.2.840.10008.5.1.1.18	Basic Color Print Management Meta SOP Class	Print Management
1.2.840.10008.5.1.1.23	Presentation LUT SOP Class	Print Management
1.2.840.10008.5.1.1.24.1	Basic Print Image Overlay Box SOP Class	Print Management
1.2.840.10008.5.1.1.33	Media Creation Management SOP Class UID	Print Management
1.2.840.10008.5.1.4.1.1.1	Computed Radiography Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.1.1	Digital X-Ray Image Storage - For Presentation	Transfer
1.2.840.10008.5.1.4.1.1.1.1.1	Digital X-Ray Image Storage - For Processing	Transfer
1.2.840.10008.5.1.4.1.1.1.2	Digital Mammography X-Ray Image Storage - For Presentation	Transfer
1.2.840.10008.5.1.4.1.1.1.2.1	Digital Mammography X-Ray Image Storage - For Processing	Transfer
1.2.840.10008.5.1.4.1.1.1.3	Digital Intra-oral X-Ray Image Storage - For Presentation	Transfer
1.2.840.10008.5.1.4.1.1.1.3.1	Digital Intra-oral X-Ray Image Storage - For Processing	Transfer
1.2.840.10008.5.1.4.1.1.2	CT Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.2.1	Enhanced CT Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.3.1	Ultrasound Multi-frame Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.4	MR Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.4.1	Enhanced MR Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.4.2	MR Spectroscopy Storage	Transfer
1.2.840.10008.5.1.4.1.1.4.3	Enhanced MR Color Image Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.6.1	Ultrasound Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.6.2	Enhanced US Volume Storage	Transfer
1.2.840.10008.5.1.4.1.1.7	Secondary Capture Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.7.1	Multi-frame Single Bit Secondary Capture Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.7.2	Multi-frame Grayscale Byte Secondary Capture Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.7.3	Multi-frame Grayscale Word Secondary Capture Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.7.4	Multi-frame True Color Secondary Capture Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.1.1	12-lead ECG Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.1.2	General ECG Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.1.3	Ambulatory ECG Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.2.1	Hemodynamic Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.3.1	Cardiac Electrophysiology Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.4.1	Basic Voice Audio Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.4.2	General Audio Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.5.1	Arterial Pulse Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.9.6.1	Respiratory Waveform Storage	Transfer
1.2.840.10008.5.1.4.1.1.11.1	Grayscale Softcopy Presentation State Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.11.2	Color Softcopy Presentation State Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.11.3	Pseudo-Color Softcopy Presentation State Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.11.4	Blending Softcopy Presentation State Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.11.5	XA/XRF Grayscale Softcopy Presentation State Storage	Transfer
1.2.840.10008.5.1.4.1.1.12.1	X-Ray Angiographic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.12.1.1	Enhanced XA Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.12.2	X-Ray Radiofluoroscopic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.12.2.1	Enhanced XRF Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.13.1.1	X-Ray 3D Angiographic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.13.1.2	X-Ray 3D Craniofacial Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.13.1.3	Breast Tomosynthesis Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.14.1	Intravascular Optical Coherence Tomography Image Storage - For Presentation	Transfer
1.2.840.10008.5.1.4.1.1.14.2	Intravascular Optical Coherence Tomography Image Storage - For Processing	Transfer
1.2.840.10008.5.1.4.1.1.20	Nuclear Medicine Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.66	Raw Data Storage	Transfer
1.2.840.10008.5.1.4.1.1.66.1	Spatial Registration Storage	Transfer
1.2.840.10008.5.1.4.1.1.66.2	Spatial Fiducials Storage	Transfer
1.2.840.10008.5.1.4.1.1.66.3	Deformable Spatial Registration SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.66.4	Segmentation SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.66.5	Surface Segmentation Storage	Transfer
1.2.840.10008.5.1.4.1.1.67	Real World Value Mapping Storage	Transfer
1.2.840.10008.5.1.4.1.1.68.1	Surface Scan Mesh Storage	Transfer
1.2.840.10008.5.1.4.1.1.68.2	Surface Scan Point Cloud Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.1	VL Endoscopic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.1.1	Video Endoscopic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.2	VL Microscopic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.2.1	Video Microscopic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.3	VL Slide-Coordinates Microscopic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.4	VL Photographic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.4.1	Video Photographic Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.5.1	Ophthalmic Photography 8 Bit Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.5.2	Ophthalmic Photography 16 Bit Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.5.3	Stereometric Relationship Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.5.4	Ophthalmic Tomography Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.77.1.6	VL Whole Slide Microscopy Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.1	Lensometry Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.2	Autorefraction Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.3	Keratometry Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.4	Subjective Refraction Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.5	Visual Acuity Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.6	Spectacle Prescription Report Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.7	Ophthalmic Axial Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.78.8	Intraocular Lens Calculations Storage	Transfer
1.2.840.10008.5.1.4.1.1.79.1	Macular Grid Thickness and Volume Report Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.80.1	Ophthalmic Visual Field Static Perimetry Measurements Storage	Transfer
1.2.840.10008.5.1.4.1.1.81.1	Ophthalmic Thickness Map Storage	Transfer
1.2.840.10008.5.1.4.1.1.82.1	Corneal Topography Map Storage	Transfer
1.2.840.10008.5.1.4.1.1.88.11	Basic Text SR	Transfer
1.2.840.10008.5.1.4.1.1.88.22	Enhanced SR	Transfer
1.2.840.10008.5.1.4.1.1.88.33	Comprehensive SR	Transfer
1.2.840.10008.5.1.4.1.1.88.34	Comprehensive 3D SR	Transfer
1.2.840.10008.5.1.4.1.1.88.40	Procedure Log Storage	Transfer
1.2.840.10008.5.1.4.1.1.88.50	Mammography CAD SR	Transfer
1.2.840.10008.5.1.4.1.1.88.59	Key Object Selection Document	Transfer
1.2.840.10008.5.1.4.1.1.88.65	Chest CAD SR	Transfer
1.2.840.10008.5.1.4.1.1.88.67	X-Ray Radiation Dose SR	Transfer
1.2.840.10008.5.1.4.1.1.88.69	Colon CAD SR	Transfer
1.2.840.10008.5.1.4.1.1.88.70	Implantation Plan SR Document Storage	Transfer
1.2.840.10008.5.1.4.1.1.104.1	Encapsulated PDF Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.104.2	Encapsulated CDA Storage SOP Class	Transfer
1.2.840.10008.5.1.4.1.1.128	Positron Emission Tomography Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.130	Enhanced PET Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.131	Basic Structured Display Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.1	RT Image Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.2	RT Dose Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.3	RT Structure Set Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.4	RT Beams Treatment Record Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.5	RT Plan Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.6	RT Brachy Treatment Record Storage	Transfer
1.2.840.10008.5.1.4.1.1.481.7	RT Treatment Summary Record Storage	Transfer
1.2.840.10008.5.1.4.1.2.1.1	Patient Root Query/Retrieve Information Model - FIND	Query/Retrieve
1.2.840.10008.5.1.4.1.2.1.2	Patient Root Query/Retrieve Information Model - MOVE	Query/Retrieve
1.2.840.10008.5.1.4.1.2.1.3	Patient Root Query/Retrieve Information Model - GET	Query/Retrieve
1.2.840.10008.5.1.4.1.2.2.1	Study Root Query/Retrieve Information Model - FIND	Query/Retrieve
1.2.840.10008.5.1.4.1.2.2.2	Study Root Query/Retrieve Information Model - MOVE	Query/Retrieve
1.2.840.10008.5.1.4.1.2.2.3	Study Root Query/Retrieve Information Model - GET	Query/Retrieve
1.2.840.10008.5.1.4.1.2.4.2	Composite Instance Root Retrieve - MOVE	Query/Retrieve
1.2.840.10008.5.1.4.1.2.4.3	Composite Instance Root Retrieve - GET	Query/Retrieve
1.2.840.10008.5.1.4.1.2.5.3	Composite Instance Retrieve Without Bulk Data - GET	Query/Retrieve
1.2.840.10008.5.1.4.31	Modality Worklist Information Model - FIND	Workflow Management
1.2.840.10008.5.1.4.32.1	General Purpose Worklist Information Model - FIND (Retired)	Workflow Management
1.2.840.10008.5.1.4.32.2	General Purpose Scheduled Procedure Step SOP Class (Retired)	Workflow Management
1.2.840.10008.5.1.4.32.3	General Purpose Performed Procedure Step SOP Class (Retired)	Workflow Management
1.2.840.10008.5.1.4.32	General Purpose Worklist Management Meta SOP Class (Retired)	Workflow Management
1.2.840.10008.5.1.4.33	Instance Availability Notification SOP Class	Workflow Management
1.2.840.10008.5.1.4.34.6.1	Unified Procedure Step - Push SOP Class	Workflow Management
1.2.840.10008.5.1.4.34.6.2	Unified Procedure Step - Watch SOP Class	Workflow Management
1.2.840.10008.5.1.4.34.6.3	Unified Procedure Step - Pull SOP Class	Workflow Management
1.2.840.10008.5.1.4.34.6.4	Unified Procedure Step - Event SOP Class	Workflow Management
1.2.840.10008.5.1.4.34.7	RT Beams Delivery Instruction Storage	Transfer
1.2.840.10008.5.1.4.34.8	RT Conventional Machine Verification	Workflow Management
1.2.840.10008.5.1.4.34.9	RT Ion Machine Verification	Workflow Management
1.2.840.10008.5.1.4.37.1	General Relevant Patient Information Query	Query/Retrieve
1.2.840.10008.5.1.4.37.2	Breast Imaging Relevant Patient Information Query	Query/Retrieve
1.2.840.10008.5.1.4.37.3	Cardiac Relevant Patient Information Query	Query/Retrieve
1.2.840.10008.5.1.4.38.1	Hanging Protocol Storage	Transfer
1.2.840.10008.5.1.4.38.2	Hanging Protocol Information Model - FIND	Query/Retrieve
1.2.840.10008.5.1.4.38.3	Hanging Protocol Information Model - MOVE	Query/Retrieve
1.2.840.10008.5.1.4.39.1	Color Palette Storage	Transfer
1.2.840.10008.5.1.4.39.2	Color Palette Information Model - FIND	Query/Retrieve
1.2.840.10008.5.1.4.39.3	Color Palette Information Model - MOVE	Query/Retrieve
1.2.840.10008.5.1.4.39.4	Color Palette Information Model - GET	Query/Retrieve
1.2.840.10008.5.1.4.41	Product Characteristics Query	Query/Retrieve
1.2.840.10008.5.1.4.42	Substance Approval Query	Query/Retrieve
1.2.840.10008.5.1.4.43.1	Generic Implant Template Storage	Transfer
1.2.840.10008.5.1.4.43.2	Generic Implant Template Information Model - FIND	Query / Retrieve
1.2.840.10008.5.1.4.43.3	Generic Implant Template Information Model - MOVE	Query / Retrieve
1.2.840.10008.5.1.4.43.4	Generic Implant Template Information Model - GET	Query / Retrieve
1.2.840.10008.5.1.4.44.1	Implant Assembly Template Storage	Transfer
1.2.840.10008.5.1.4.44.2	Implant Assembly Template Information Model - FIND	Query / Retrieve
1.2.840.10008.5.1.4.44.3	Implant Assembly Template Information Model - MOVE	Query / Retrieve
1.2.840.10008.5.1.4.44.4	Implant Assembly Template Information Model - GET	Query / Retrieve
1.2.840.10008.5.1.4.45.1	Implant Template Group Storage	Transfer
1.2.840.10008.5.1.4.45.2	Implant Template Group Information Model - FIND	Query / Retrieve
1.2.840.10008.5.1.4.45.3	Implant Template Group Information Model - MOVE	Query / Retrieve
1.2.840.10008.5.1.4.45.4	Implant Template Group Information Model - GET	Query / Retrieve

A table of Supported Media Storage Application Profiles (with roles) is provided, organized in 3 categories:

Compact Disk - Recordable
Magneto-Optical Disk
DVD

Table A.1-3. Media Services

Media Storage Application Profile	Write Files (FSC or FSU)	Read Files (FSR)
Compact Disk - Recordable
General Purpose CD-R	Option	Yes
Magneto-Optical Disk
CT/MR 2.3 GB MOD	Yes	Yes
DVD
General Purpose DVD-RAM	Yes	Yes

A.2 Table of Contents

The table of contents will be provided to assist readers in easily finding the needed information.

A.3 Introduction

The introduction specifies product and relevant disclaimers as well as any general information that the vendor feels is appropriate.

The following subsections are suggested:

A.3.1 Revision History

The revision history provides dates and differences of the different releases of the product and the Conformance Statement.

A.3.2 Audience

The audience is specified with their assumed pre-knowledge. The following example may be used as a template:

This document is written for the people that need to understand how <Product Name> will integrate into their healthcare facility. This includes both those responsible for overall imaging network policy and architecture, as well as integrators who need to have a detailed understanding of the DICOM features of the product. This document contains some basic DICOM definitions so that any reader may understand how this product implements DICOM features. However, integrators are expected to fully understand all the DICOM terminology, how the tables in this document relate to the product's functionality, and how that functionality integrates with other devices that support compatible DICOM features.

A.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 Name> and other DICOM products. The Conformance Statement should be read and understood in conjunction with the DICOM Standard. 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 is not supposed to replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, the user should be aware of the following important issues:

The comparison of different Conformance Statements is just the first step towards assessing interconnectivity and interoperability between the product and other DICOM conformant equipment.
Test procedures should be defined and executed to validate the required level of interoperability with specific compatible DICOM equipment, as established by the healthcare facility.

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

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

A.3.4 Terms and Definitions

Terms and definitions should be listed here. The following example may be used as a template:

Informal definitions are provided for the following terms used in this Conformance Statement. The DICOM Standard is the authoritative source for formal definitions of these terms.

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) : an end point of a DICOM information exchange, including the DICOM network or media interface software; i.e., the software that sends or receives DICOM information objects or messages. A single device may have multiple Application Entities.

Application Entity Title : 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 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).

Information Object Definition (IOD) : the specified set of Attributesthat 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. The Attributesmay 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). Examples: MR Image IOD, CT Image IOD, Print Job IOD.

Joint Photographic Experts Group (JPEG) - a set of standardized image compression techniques, available for use by DICOM applications.

Media Application Profile : the specification of DICOM information objects and encoding exchanged on removable media (e.g., CDs)

Module : a set of Attributeswithin an Information Object Definitionthat are logically related to each other. Example: Patient Module includes Patient Name, Patient ID, Patient Birth Date, and Patient Sex.

Negotiation : first phase of Associationestablishment that allows Application Entitiesto agree on the types of data to be exchanged and how that data will be encoded.

Presentation Context : the set of DICOM network services used over an Association, as negotiated between Application Entities; includes Abstract Syntaxesand Transfer Syntaxes.

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 Entityto ensure confidentiality, integrity, and/or availability of exchanged DICOM data

Service Class Provider (SCP) : role of an Application Entitythat 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 Entitythat 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 (SOP) Class : the specification of the network or media transfer (service) of a particular type of data (object); the fundamental unit of DICOM interoperability specification. Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management.

Service/Object Pair (SOP) Instance : an information object; a specific occurrence of information exchanged in a SOP Class. Examples: a specific x-ray image.

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: JPEGcompressed (images), little endian explicit value representation.

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.

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.

A.3.5 Basics of DICOM Communication

A layman's introduction to DICOM may be included here. The following example may be used as a template:

This section describes terminology used in this Conformance Statement for the non-specialist. The key terms used in the Conformance Statement are highlighted in italicsbelow. This section is not a substitute for training about DICOM, and it makes many simplifications about the meanings of DICOM terms.

Two Application Entities (devices) that want to communicate with each other over a network using DICOM protocol must first agree on several things during an initial network "handshake". One of the two devices must initiate an Association (a connection to the other device), and ask if specific services, information, and encoding can be supported by the other device (Negotiation).

DICOM specifies a number of network services and types of information objects, each of which is called an Abstract Syntax for the Negotiation. DICOM also specifies a variety of methods for encoding data, denoted Transfer Syntaxes. The Negotiation allows the initiating Application Entity to propose combinations of Abstract Syntax and Transfer Syntax to be used on the Association; these combinations are called Presentation Contexts. The receiving Application Entity accepts the Presentation Contexts it supports.

For each Presentation Context, the Association Negotiation also allows the devices to agree on Roles - which one is the Service Class User (SCU - client) and which is the Service Class Provider (SCP - server). Normally the device initiating the connection is the SCU, i.e., the client system calls the server, but not always.

The Association Negotiation finally enables exchange of maximum network packet (PDU) size, security information, and network service options (called Extended Negotiation information).

The Application Entities, having negotiated the Association parameters, may now commence exchanging data. Common data exchanges include queries for worklists and lists of stored images, transfer of image objects and analyses (structured reports), and sending images to film printers. Each exchangeable unit of data is formatted by the sender in accordance with the appropriate Information Object Definition, and sent using the negotiated Transfer Syntax. There is a Default Transfer Syntax that all systems must accept, but it may not be the most efficient for some use cases. Each transfer is explicitly acknowledged by the receiver with a Response Status indicating success, failure, or that query or retrieve operations are still in process.

Two Application Entities may also communicate with each other by exchanging media (such as a CD-R). Since there is no Association Negotiation possible, they both use a Media Application Profile that specifies "pre-negotiated" exchange media format, Abstract Syntax, and Transfer Syntax.

A.3.6 Abbreviations

Abbreviations should be listed here. These may be taken from the following list, deleting terms that are not used within the Conformance Statement, and adding any additional terms that are used:

AE: Application Entity
AET: Application Entity Title
CAD: Computer Aided Detection
CDA: Clinical Document Architecture
CD-R: Compact Disk Recordable
CSE: Customer Service Engineer
CR: Computed Radiography
CT: Computed Tomography
DHCP: Dynamic Host Configuration Protocol
DICOM: Digital Imaging and Communications in Medicine
DIT: Directory Information Tree (LDAP)
DN: Distinguished Name (LDAP)
DNS: Domain Name System
DX: Digital X-ray
FSC: File-Set Creator
FSU: File-Set Updater
FSR: File-Set Reader
GSDF: Grayscale Standard Display Function
GSPS: Grayscale Softcopy Presentation State
HIS: Hospital Information System
HL7: Health Level 7 Standard
IHE: Integrating the Healthcare Enterprise
IOD: Information Object Definition
IPv4: Internet Protocol version 4
IPv6: Internet Protocol version 6
ISO: International Organization for Standards
IO: Intra-oral X-ray
JPEG: Joint Photographic Experts Group
LDAP: Lightweight Directory Access Protocol
LDIF: LDAP Data Interchange Format
LUT: Look-up Table
MAR: Medication Administration Record
MPEG: Moving Picture Experts Group
MG: Mammography (X-ray)
MPPS: Modality Performed Procedure Step
MR: Magnetic Resonance Imaging
MSPS: Modality Scheduled Procedure Step
MTU: Maximum Transmission Unit (IP)
MWL: Modality Worklist
NM: Nuclear Medicine
NTP: Network Time Protocol
O: Optional (Key Attribute)
OP: Ophthalmic Photography
OSI: Open Systems Interconnection
PACS: Picture Archiving and Communication System
PET: Positron Emission Tomography
PDU: Protocol Data Unit
R: Required (Key Attribute)
RDN: Relative Distinguished Name (LDAP)
RF: Radiofluoroscopy
RIS: Radiology Information System.
RT: Radiotherapy
SC: Secondary Capture
SCP: Service Class Provider
SCU: Service Class User
SOP: Service-Object Pair
SPS: Scheduled Procedure Step
SR: Structured Reporting
TCP/IP: Transmission Control Protocol/Internet Protocol
U: Unique (Key Attribute)
UL: Upper Layer
US: Ultrasound
VL: Visible Light
VR: Value Representation
XA: X-ray Angiography

A.3.7 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:

NEMA PS3 Digital Imaging and Communications in Medicine (DICOM) Standard, available free at http://medical.nema.org/

A.4 Networking

This section contains the networking related services (vs. the media related ones).

A.4.1 Implementation Model

The Implementation model consists of three sections: the Application Data Flow Diagram, specifying the relationship between the Application Entities and the "external world" or Real-World activities, a functional description of each Application Entity, and the sequencing constraints among them.

A.4.1.1 Application Data Flow

As part of the Implementation model, an Application Data Flow Diagram shall be included. This diagram represents all of the Application Entities present in an implementation, and graphically depicts the relationship of the AEs use of DICOM to Real-World Activities as well as any applicable User interaction. Figure A.4.1-1 is a template for such a Data Flow Diagram.

In this illustration, according to figure A.4.1-1, an occurrence of local Real-World Activity A will cause local Application Entity <1> to initiate an association for the purpose of causing Real-World Activity X to occur remotely. It also shows that Real-World Activities B and Y are interactively related via Application Entity <2>, with B being local and Y Remote, and that local Application Entity 3 expects to receive an association request when remote Real-World Activity Z occurs so that it can perform Real-World Activity C and/or D. When the performance of Real-World activities relies on interactions within the implementation, one may depict the circles as overlapping as shown in Figure A.4.1-1. Any such overlap shall be discussed in this section of a Conformance Statement.

Typically, there is a one to one relationship between an AE and an AE Title. Devices may be capable of configuring the relationship between AE and AE Title (e.g., by merging Application Entities to use a single AE Title). This is specified in the configuration section.

Figure A.4.1-1. Functional Overview

The Application Data Flow Diagram shall contain overview text with one bullet per AE. Each bullet should provide an overview of each one of the AEs, in relationship to their real-world activities, AE network exchanges and external real-world activities.

Note

There is no standard definition or guidelines on the number of AEs within a product and what an AE should encompass. Its functionality and scope is purely to the discretion of the vendor and typically depending on the system architecture.

A.4.1.2 Functional Definition of AEs

This part shall contain a functional definition for each individual local Application Entity. This shall describe in general terms the functions to be performed by the AE, and the DICOM services used to accomplish these functions. In this sense, "DICOM services" refers not only to DICOM Service Classes, but also to lower level DICOM services, such as Association Services.

A.4.1.2.1 Functional Definition of "Application Entity <1>"

Functional description of "Application Entity <1>" (substitute actual AE name), i.e., what is it that the AE performs.

A.4.1.2.2 Functional Definition of "Application Entity <2>"

Same for "Application Entity <2>".

A.4.1.2.3 Functional Definition of "Application Entity <3>"

Same for "Application Entity <3>".

A.4.1.3 Sequencing of Real World Activities

If applicable, this section shall contain a description of sequencing as well as potential constraints, of Real-World Activities, including any applicable user interactions, as performed by all the Application Entities. A UML sequence diagram, which depicts the Real-World Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.

A.4.2 AE Specifications:

The next section in the DICOM Conformance Statement is a set of Application Entity Specifications. There shall be one such specification for each Application Entity. Each individual AE Specification has a subsection, A.4.2.x. There are as many of these subsections as there are different AEs in the implementation. That is, if there are two distinct AEs, then there will be two subsections, A.4.2.1, and A.4.2.2.

A.4.2.1 "Application Entity <1>"

Every detail of this specific Application Entity shall be completely specified under this section.

AEs that utilize the DIMSE services shall have the following sections.

Note

AEs that utilize other services are described later, and will re-use this section numbering.

A.4.2.1.1 SOP Classes

The specification for an Application Entity shall contain a statement of the form:

"This Application Entity provides Standard Conformance to the following SOP Class(es) :"

Table A.4.2-1. SOP Class(Es) for "Application Entity <1>"

SOP Class Name	SOP Class UID	SCU	SCP
SOP Class UID Name as specified in the registry table of DICOM Unique Identifiers (UID) in PS3.6, with phrase "and specializations" as appropriate	UID as specified in PS3.6	Yes/No	Yes/No

Note

Any SOP specific behavior is documented later in the conformance statement in the applicable SOP specific conformance section.

A.4.2.1.2 Association Policies

Each AE Specification shall contain a description of the General Association Establishment and Acceptance policies of the AE.

A.4.2.1.2.1 General

The DICOM standard Application context shall be specified.

Table A.4.2-2. DICOM Application Context

Application Context Name

1.2.840.10008.3.1.1.1

A.4.2.1.2.2 Number of Associations.

The number of simultaneous associations, which an Application Entity may support as a SCU or SCP, shall be specified. Any rules governing simultaneity of associations shall be defined here.

Note

For example an AE may have the capability to have up to 10 simultaneous associations, but may limit itself to have no more than 2 with any particular other AE. There may also be policies based upon combinations of simultaneous Real-World Activities.

Table A.4.2-3. Number of Associations as an Association Initiator for "Application Entity <1>"

Maximum number of simultaneous associations

Table A.4.2-4. Number of Associations as an Association Acceptor for "Application Entity <1>"

Maximum number of simultaneous associations

A.4.2.1.2.3 Asynchronous Nature

If the implementation supports negotiation of multiple outstanding transactions, this shall be stated here, along with the maximum number of outstanding transactions supported.

Table A.4.2-5. Asynchronous Nature as an Association Initiator for "Application Entity <1>"

Maximum number of outstanding asynchronous transactions

A.4.2.1.2.4 Implementation Identifying Information

The value supplied for Implementation Class UID shall be documented here. If a version name is supplied, this fact shall be documented here. Policies defining the values supplied for version name may be stated here.

Table A.4.2-6. DICOM Implementation Class and Version for "Application Entity <1>"

Implementation Class UID	a.b.c.xxxxxxx.yyy.zz
Implementation Version Name	XYZxyz

A.4.2.1.3 Association Initiation Policy

This describes the conditions under which the AE will initiate an association.

A.4.2.1.3.1 "Activity <1>"

A.4.2.1.3.1.1 Description and Sequencing of Activities

If applicable, this section shall contain a description of sequencing of the events for "Activity <1>" (substitute actual activity name), including any applicable user interactions, which this specific AE performs. A UML sequence diagram, which depicts the Application Entity and Real-World Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.

Note

An example of a situation in which such a description is required is an AE, which supports both the Storage Service Class and the Modality Performed Procedure SOP Class. Some implementations might store the images before sending the final MPPS N-SET message while other implementations might send the final MPPS N-SET message before sending the images.

A.4.2.1.3.1.2 Proposed Presentation Contexts

Each time an association is initiated, the Association Initiator proposes a number of Presentation Contexts to be used on that association. In this subsection, the Presentation Contexts proposed by "Application Entity <1>" for "Activity <1>" shall be defined in a table with the following format:

Table A.4.2-7. Proposed Presentation Contexts for "Application Entity <1>"

Presentation Context Table
Abstract Syntax		Transfer Syntax		Role	Extended Negotiation
Name	UID	Name List	UID List	Role	Extended Negotiation
name_a	AS_UID_a	XS_Name_1, ..., XS_Name_n	XS_UID_1, _, XS_UID_n	SCP \| SCU \| BOTH	None \|See Note <1> \| See Table A.4.2-8
...	...	...	...	...	...

Note

<1>: <Describe the content of any extended negotiation done for the SOP Classes of this Presentation Context. One note may serve multiple Presentation Contexts, as a single Abstract Syntax often corresponds to a single SOP class, which may appear in different Presentation Contexts.>

In Table A.4.2-7, the following meanings are assigned to the fields:

<name_a> This is the name of the Abstract Syntax to be used with this Presentation Context.
<AS_UID_a> This is the UID of the Abstract Syntax to be used for this Presentation Context.
<XS_Name_n> This is the name of a Transfer Syntax that may be used for this Presentation Context.
<XS_UID_n> The UID of the corresponding Transfer Syntax.

If the AE through this Real World Activity might propose any of the SOP Classes of a particular Service Class (e.g., the Storage Service Class), the Abstract Syntax Name and UID shall be those of the Service Class. This section shall describe the conditions under which a SOP Class of that Service Class will be proposed in a Presentation Context.

Note

For instance, an AE may receive instances of a non-preconfigured SOP Class through support of SOP Class Common Extended Negotiation. These instances may be limited to specializations of a particular SOP Class, or they may be any SOP Class within the Service Class, and any such limits should be described.

This section shall describe the conditions under which the AE may change the SOP Class UID of SOP Instances sent, due to fall-back mechanisms.

Note

For instance, if the SCP does not accept the proposed Abstract Syntax (SOP Class) for which there is a Related General SOP Class that was accepted, the AE may modify SOP Instances of the refused SOP Class to use the Related General SOP Class for transmission.

In the event that the Abstract Syntax of the Presentation Context represents a Meta-SOP Class (that is, it includes many SOP Classes) and extended negotiation is supported for some of these SOP Classes, the following table is required to define this extended negotiation. This table is referenced in Table A.4.2-7:

Table A.4.2-8. Extended Negotiation as a SCU

SOP Class Name	SOP Class UID	Extended Negotiation
Name_i	SOP_UID_I	None \| See Note <1>
...	...	...

Note

<1>: <Describe the content of any extended negotiation done for this SOP Class. One note may serve multiple Presentation Contexts, as a SOP class that may appear in different Presentation Contexts and/or Meta SOP Classes>

The implementation of the initiator shall document which Transfer Syntax will be chosen in case multiple Transfer Syntaxes are accepted during the Association Acceptance.

A.4.2.1.3.1.3 SOP Specific Conformance for SOP Class(Es)

This section includes the SOP specific behavior, i.e., error codes, error and exception handling, time-outs, etc. The information shall be as described in the SOP specific Conformance Statement section of PS3.4 (or relevant private SOP definition). It shall include the content of any extended negotiation. Keys shall be specified including how they are used (Matching, return keys, interactive query, whether they are displayed to the user, universal and/or list matching, etc.).

In particular, the behavior associated with the exchange of images available to the AE only in a lossy compressed form shall be documented. For example, if a lossy compressed transfer syntax is not negotiated, will the AE decompress the image data and send it using one of the negotiated transfer syntaxes.

All details regarding the specific conformance, including response behavior to all status codes, both from an application level and communication errors shall be provided in the form of a table as follows:

Table A.4.2-9. DICOM Command Response Status Handling Behavior

Service Status	Further Meaning	Error Code	Behavior
e.g., Success	e.g., Matching is complete	e.g., 0000	e.g., The SCP has successfully returned all matching information.
Warning
Error
…..

The behavior of the AE during communication failure is summarized in a table as follows:

Table A.4.2-10. DICOM Command Communication Failure Behavior

Exception	Behavior
e.g., Timeout	e.g., The Association is aborted using A-ABORT and command marked as failed. The reason is logged and reported to the user.
e.g., Association aborted	e.g., The command is marked as failed. The reason is logged and reported to the user.

A.4.2.1.4 Association Acceptance Policy

Each AE Specification shall contain a description of the Association Acceptance policies of the AE. This describes the conditions under which the AE will accept an association.

A.4.2.1.4.1 "Activity <2>"

A.4.2.1.4.1.1 Description and Sequencing of Activities

A.4.2.1.4.1.2 Accepted Presentation Contexts

Table A.4.2-11. Acceptable Presentation Contexts For"Application Entity <1>" and "Activity <2>"

Presentation Context Table
Abstract Syntax		Transfer Syntax		Role	Extended Negotiation
Name	UID	Name	UID	Role	Extended Negotiation
name_a	AS_UID_a	XS_Name_a	XS_UID_a	SCP \| SCU \| Both	None \|See Note <1>\| See Table A.4.2-12
...	...	...	...	...	...

Note

<1>: <Describe the content of any extended negotiation done for the SOP Classes of this Presentation Context. In particular, acceptance of specialized SOP Classes of the Abstract Syntax specified in this Presentation Context shall be noted. One note may serve multiple Presentation Contexts, as a single Abstract Syntax often corresponds to a single SOP class, which may appear in different Presentation Contexts>

In Table A.4.2-11, the following meanings are assigned to the fields:

<name_a> This is the name of the Abstract Syntax to be used with this Presentation Context.

<AS_UID_a> This is the UID of the Abstract Syntax to be used for this Presentation Context.

<XS_Name_a> This is the name of a Transfer Syntax that may be used for this Presentation Context.

<XS_UID_a> The UID of the corresponding transfer syntax.

If the AE through this Real World Activity supports all SOP Classes of a particular Service Class (e.g., the Storage Service Class) through SOP Class Common Extended Negotiation, the Abstract Syntax Name and UID shall be those of the Service Class, and this shall be noted under Extended Negotiation.

Table A.4.2-12. Extended Negotiation as a SCP

SOP Class name	SOP Class UID	Extended Negotiation
Name_i	SOP_UID_I	None \| See Note <1>
...	...	...

Note

<1>: <Describe the content of any extended negotiation done for this SOP Class. One note may serve multiple Presentation Contexts, as a SOP class, which may appear in different Presentation Contexts, and/or Meta SOP Classes>

Any rules that govern the acceptance of presentation contexts for this AE shall be stated here as well. This includes rules for which combinations of Abstract/Transfer Syntaxes are acceptable, and rules for prioritization of presentation contexts. Rules that govern selection of transfer syntax within a presentation context shall be stated here.

A.4.2.1.4.1.3 SOP Specific Conformance for SOP Class(Es)

The behavior of an Application Entity shall be summarized as shown in Table 4.2-13. Standard as well as the manufacturer specific status codes and their corresponding behavior shall be specified.

Table 4.2-13. Storage C-STORE Response Status

Service Status	Further Meaning	Error Code	Reason
Success	Success	0000	Explain
Refused	Out of Resources	A700-A7FF	Explain
Error	Data Set does not match SOP Class	A900-A9FF	Explain
Error	Specify	Specify	Explain
Warning	Specify	Specify	Explain

A.4.2.2 "Application Entity <1>"

An Application Entity that supports the WADO transport services shall have the following sections:

Details of this specific Application Entity shall be specified under this section.

A.4.2.2.1 WADO-WS Specifications

All WADO WS services that are supported shall be listed. Other WADO WS services that are not supported may be indicated.

For each supported service, the parameters and restrictions on those parameters shall be described.

Any connection policies such as restrictions on the number of connections, support for asynchronous WS requests, etc. shall be described.

A.4.2.2.2 WADO-URI Specifications

All WADO-URI services that are supported shall be listed. Other WADO-URI services that are not supported may be indicated.

For each supported service, the parameters and restrictions on those parameters shall be described.

Any connection policies such as restrictions on the number of connections, support for pipeline requests, etc. shall be described.

A.4.2.2.3 Restful Services Specifications

All RESTful services that are supported shall be listed. Other RESTful services that are not supported may be indicated.

For each supported service, the parameters and restrictions on those parameters shall be described.

Any connection policies such as restrictions on the number of connections, support for pipeline requests, etc. shall be described.

A.4.2.3 "Application Entity <2>"

The same info shall be repeated for each additional AE.

A.4.3 Network Interfaces

A.4.3.1 Physical Network Interface

If applicable, specifies what physical network interface(s) are supported.

A.4.3.2 Additional Protocols

Additional protocols such as used for configuration management are listed here. Any conformance to specific System Management Profiles defined in PS3.15 shall be listed per the following table.

Table A.4.3-1. System Management Profiles Table

Profile Name	Actor	Protocols Used	Optional Transactions	Security Support
Profile (1)	P Client	Protocol_1, Protocol_2	N/A
Profile (x)	X Client	Protocol_2, Protocol_3	Protocol_3 Option_A supported

If the implementation conforms to the Basic Network Address Management Profile as a DHCP Client actor (see PS3.15), the use of DHCP to configure the local IP address and hostname shall be described.

Note

The hostname is an alias for the IP address, and has no semantic relationship to AE titles. It is solely a convenience for configuration description.

If the implementation conforms to the Basic Network Address Management Profile as a DNS Client actor (see PS3.15), the use of DNS to obtain IP addresses from hostname information shall be described.

If the implementation conforms to the Basic Time Synchronization profile as an NTP Client or SNTP Client, the available NTP configuration alternatives shall be described. If the implementation conforms to the Basic Time Synchronization Profile as an NTP Server, the available server configuration alternatives shall be described. Any device specific requirements for accuracy or maximum allowable synchronization error shall be described.

If there is support for WADO (see PS3.18) the options supported and any restrictions shall be described.

A.4.3.3 IPv4 and IPv6 Support

The support for specific IPv4 and IPv6 features and associated optional IPv6 security and configuration facilities shall be documented.

A.4.4 Configuration

Any implementation's DICOM conformance may be dependent upon configuration, which takes place at the time of installation. Issues concerning configuration shall be addressed in this section.

A.4.4.1 AE Title/Presentation Address Mapping

An important installation issue is the translation from AE title to Presentation Address. How this is to be performed shall be described in this section.

Note

There does not necessarily have to be a one to one relationship between AE titles and Application Entities. If so, this should be made clear in the tables.

A.4.4.1.1 Local AE Titles.

The local AE title mapping and configuration shall be specified. The following table shall be used:

Table A.4.4-1. AE Title Configuration Table

Application Entity	Default AE Title	Default TCP/IP Port
AE (1)	Name	Specify
AE (2)	Name	Specify
AE (x)

If the implementation conforms to the Application Configuration Management Profile as an LDAP Client actor (see PS3.15), any use of LDAP to configure the local AE titles shall be described. Any conformance to the Update LDAP Server option shall be specified, together with the values for all component object attributes in the update sent to the LDAP Server.

A.4.4.1.2 Remote AE Title/Presentation Address Mapping

Configuration of remote host names and port numbers shall be specified here.

A.4.4.1.2.1 Remote SCP 1

Configuration of the remote AET port number, host-names, IP addresses and capabilities shall be specified. If applicable, multiple remote SCPs can be specified.

If the implementation conforms to the Application Configuration Management Profile as an LDAP Client actor (see PS3.15), any use of LDAP to configure the remote device addresses and capabilities shall be described. The LDAP queries used to obtain remote device component object attributes shall be specified.

Note

In particular, use of LDAP to obtain the AE Title, TCP port, and IP address for specific system actors (e.g., an Image Archive, or a Performed Procedure Step Manager) should be detailed, as well as how the LDAP information for remote devices is selected for operational use.

A.4.4.1.2.2 Remote SCP 2

Etc.

A.4.4.2 Parameters

The specification of important operational parameters, and if configurable, their default value and range, shall be specified here. The parameters that apply to all Application Entities should be specified in a "General Parameters" section while those specific to particular Application Entities should be specified in separate sections specific to each AE. The following table, which is shown here with a recommended baseline of parameters, shall be used:

Table A.4.4-2. Configuration Parameters Table

Parameter	Configurable (Yes/No)	Default Value
General Parameters
Time-out waiting for acceptance or rejection Response to an Association Open Request. (Application Level timeout)
General DIMSE level time-out values
Time-out waiting for response to TCP/IP connect request. (Low-level timeout)
Time-out waiting for acceptance of a TCP/IP message over the network. (Low-level timeout)
Time-out for waiting for data between TCP/IP packets. (Low-level timeout)
Any changes to default TCP/IP settings, such as configurable stack parameters.
Definition of arbitrarily chosen origins
Definition of constant values used in Dose Related Distance Measurements
Other configurable parameters
AE Specific Parameters
Size constraint in maximum object size (see note)
Maximum PDU size the AE can receive
Maximum PDU size the AE can send
AE specific DIMSE level time-out values
Number of simultaneous Associations by Service and/or SOP Class
<SOP Class support> (e.g., Multi-frame vs. single frame vs. SC support), when configurable
<Transfer Syntax support>, e.g., JPEG, Explicit VR, when configurable
Other parameters that are configurable

Note

In particular when accommodating Multi-frame objects (e.g., Ultrasound Multi-frame, NM, XA, RF), a receiver might have a certain restriction with regard to its maximum length. This restriction should be specified here.

Additional configuration parameters such as hardware options for e.g., a printer shall be specified as well.

A.5 Media Interchange

A.5.1 Implementation Model

The Implementation Model shall identify the DICOM Application Entities in a specific implementation and relate the Application Entities to Real-World Activities.

A.5.1.1 Application Data Flow Diagram

As part of the Implementation Model, an Application Data Flow Diagram shall be included. This diagram represents all of the Application Entities present in an implementation and graphically depicts the relationship of the AEs use of DICOM to real world activities. Figure A.5.1-1 is a template for such a Data Flow Diagram. Accompanying the Application Data Flow Diagram shall be a discussion of the Application Data Flow represented.

In this illustration, according to Figure A.5.1-1, an occurrence of local Real-World Activity A or B will cause the local Application Entity 1 to initiate either creation of a File-set on a medium (FSC) for the purpose of interchange with a remote Real-World Activity X or to access a File-set on a medium for reading (FSR). The remote Real-World Activity X accesses the medium physically transferred from Real-World Activity A or B.

An occurrence of Real-World Activity C will cause the local Application Entity 2 to update a File-set (FSU) on a mounted medium.

Figure A.5.1-1. Application Data Flow Diagram

Note

If the AE expects a remote Real-World Activity to access the media for a specific purpose, this should be shown in the Application Data Flow Diagram as well as described in Section Section A.5.1.1.

A.5.1.2 Functional Definitions of AEs

The next part of the Conformance Statement shall contain a functional definition for each local Application Entity. This shall describe in general terms the functions to be performed by the AE, and the DICOM services used to accomplish these functions. In this sense "DICOM services" refers not only to DICOM Service Classes, but also to lower level DICOM services, such as the Media File System and mapping to particular Media Formats.

A.5.1.3 Sequencing of Real World Activities

If applicable, this section shall contain a description of sequencing of Real World Activities that the AEs require.

Note

An example of a situation in which a such a description is required is an AE that supports roles as a File-set Updater and File-set Reader. In some instances, the File-set will be updated then read (e.g., for verification); and in other instances, may be read first to determine if the File-set needs to be updated.

A.5.1.4 File Meta Information for Implementation Class and Version

This section shall be used to list the values assigned to the File Meta Information attributes (see PS3.10) that pertain to the Implementation Class and Version. These are:

File Meta Information Version
Implementation Class UID
Implementation Version Name

A.5.2 AE Specifications

The next section in the DICOM Conformance Statement is a set of Application Entity Specifications. There shall be one such specification for each Application Entity type.

A.5.2.1 "Application Entity <1>" - Specification

The following table, Table A.5.2-1, shows that for one or more Application Profiles in the first column, there are a number of Real-World Activities in the second column and the roles required for each of these Real-World Activities in the third column

Table A.5.2-1. AE Related Application Profiles, Real-World Activities, and Roles

Supported Application Profile	Real-World Activity	Roles
STD-AP1	RWA A	FSR
	RWA B	FSR, FSC
STD-AP1, AUG-AP2, etc.	RWA C	FSU
	RWA D	FSC

This section shall also contain any general policies that apply to all of the AEs described in subsequent section.

A.5.2.1.1 File Meta Information for the "Application Entity <1>"

This section shall contain the values of the File Meta Information that pertain to the Application Entity (see PS3.10). These are:

Source Application Entity Title

If Private Information is used in the Application Profile File Meta Information, the following two File Meta Information attributes may be documented:

Private Information Creator UID
Private Information

A.5.2.1.2 Real-World Activities

The first sentence in this section shall state the Roles and Media Storage Service Class Options supported by the "Application Entity <1>".

A.5.2.1.2.i "Real-World Activity "

The AE Specification shall contain a description of the Real-World Activities, which invoke the particular AE. There will be one section, A.5.2.1.2.i where i increments for each RWA, per Real-World Activity.

A.5.2.1.2.i.1 Media Storage Application Profile

The Application Profile that is used by the AE described in A.5.2-1 is specified in this section.

A.5.2.1.2.i.1.y Options

The options used in the Application Profiled specified in Table A.5.2-1 shall be detailed in this section. There will be separate sections for each option specified for the AP. If there are no options used in the Application Profile specified in A.5.2.x, this section may be omitted.

A.5.2.2 "Application Entity <2>" - Specification

Each individual AE Specification has a subsection, A.5.2.x. There are as many of these subsections as there are different AEs in the implementation. That is, if there are two distinct AEs, then there will be two subsections, A.5.2.1, and A.5.2.2.

A.5.3 Augmented and Private Application Profiles

This Section shall be used for the description of Augmented and Private Application Profiles.

A.5.3.1 Augmented Application Profiles

Any Augmented Application Profiles used by an AE shall be described in these sections. The rules governing the structure of an Augmented AP shall be described.

A.5.3.1.1 "Augmented Application Profile <1>"

Each Augmented Application Profile shall have a section A.5.3.1.x that describes the specific features of the Application Profile that make it Augmented. These shall be described in the three repeating sections that follow.

A.5.3.1.1.1 SOP Class Augmentations

The additional SOP Classes beyond those specified in the Standard AP on which this Augmented AP is based shall be detailed in this section.

A.5.3.1.1.2 Directory Augmentations

Any additions to the Directory IOD that augment this AP shall be described in this section.

A.5.3.1.1.3 Other Augmentations

Any additions to, or extensions of the Application Profile shall be described in this section. An example of such another augmentation is addition of a role (FSR, FSC, FSU) to the Standard Application Profile set of defined roles.

A.5.3.1.2 "Augmented Application Profile <2>"

To be repeated for the second, third, etc. Augmented Application Profile.

A.5.3.2 Private Application Profiles

The rules that govern construction of a Private Application Profile shall be described. This section shall be used to describe the details of the Private AP.

Note

Refer to PS3.11 for a description of constructing a Private Application Profile.
If the AP deviates from the rules governing a Private AP in any manner, it is non-conformant and is outside the scope of this Standard.

A.5.4 Media Configuration

Any implementation's DICOM conformance may be dependent upon configuration that takes place at the time of installation. Issues concerning configuration shall be addressed in this section (e.g., the configuration of the Source AE Title in File Meta Information).

A.6 Transformation of DICOM to CDA

The supported SR objects and corresponding template identifiers shall be described. The release version and template identifier of the generated valid CDA documents shall be documented.

A.7 Support of Character Sets

Any support for Character Sets beyond the Default Character Repertoire in Network and Media Services shall be described here.

The behavior when an unsupported character set is received shall be documented.
Character set configuration capabilities, if any, shall be specified.
Mapping and/or conversion of character sets across Services and Instances shall be specified.
Query capabilities for attributes that include non-default character sets, both for the Worklist service class and Query service class shall be specified. Behavior of attributes using extended character sets by a C-FIND, both as SCU and SCP request and response, shall be specified. In particular the handling of Person Names (VR of PN) shall be specified.
The presentation of the characters to a user, i.e., capabilities, font limitations and/or substitutions shall be specified.

A.8 Security

A.8.1 Security Profiles

Any support for Security Profiles as defined in PS3.15 shall be described here. Any extensions to Security Profiles shall be described, e.g., extended schema for audit trail messages.

An implementation shall declare which level of security features it supports, including such things as:

The conditions under which the implementation preserves the integrity of Digital Signatures (e.g., is the implementation bit-preserving).
The conditions under which the implementation verifies incoming Digital Signatures.
The conditions under which the implementation replaces Digital Signatures.
IPv6 Security capabilities

A.8.2 Association Level Security

Any support for security at the Association level (e.g., allowing only certain AE-titles and/or IP addresses to open an Association) shall be specified here.

A.8.3 Application Level Security

Any support for additional application level security as it applies to the DICOM communication (e.g., passwords, biometrics) can be described here.

A.9 Annexes

A.9.1 IOD Contents

A.9.1.1 Created SOP Instance(s)

This section specifies each IOD created (including Private IODs). It should specify the Attribute Name, tag, VR, and Value. The Value should specify the range and source (e.g., User input, Modality Worklist, automatically generated, etc.). For content items in templates, the range and source of the concept name and concept values should be specified. Whether the value is always present or not shall be specified.

Recommended abbreviations to be used for the tables are:

VNAP Value Not Always Present (attribute sent zero length if no value is present)

ANAP Attribute Not Always Present

ALWAYS Always Present with a value

EMPTY Attribute is sent without a value

Recommended abbreviations to be used for the source of the data values in the tables are:

USER the attribute value source is from User input

AUTO the attribute value is generated automatically

MWL,MPPS, etc. the attribute value is the same as the value received using a DICOM service such as Modality Worklist, Modality Performed Procedure Step, etc.

CONFIG the attribute value source is a configurable parameter

Specification of a company web address can refer to sample SOP Instances that are available.

Private attributes should be specified.

A.9.1.2 Usage of Attributes From Received IODs

Each Application that depends on certain fields to function correctly should specify which ones are required for it to perform its intended function.

A.9.1.3 Attribute Mapping

When attributes are used by different SOP Classes, e.g., Modality Worklist, Storage and Modality Performed Procedure Step, this mapping shall be specified. For devices that specify other external protocols, such as HL7, mapping of their fields into the DICOM attributes is not required but highly recommended.

A.9.1.4 Coerced/Modified Fields

A SCU might coerce certain Attributes, e.g., the Patient Name. A SCP might provide a different value of an Attribute than was received. These changes shall be specified here. An example is Patient Name, which could be modified using available information from either an internal database or obtained from an Information System/Information Manager. Another example is the generation of a new SOP Instance UID for an existing instance. The conditions influencing such coercion should be specified..

A.9.2 Data Dictionary of Private Attributes

Any private Attributes should be specified, including VR and VM, should be specified. Private SOP Classes and Transfer syntaxes should be listed.

A.9.3 Coded Terminology and Templates

Support for Coded Terminology and templates shall be described here.

A.9.3.1 Context Groups

Each Context Group (i.e., use of coded terminology in a specific context) shall be specified here with its default value set, and whether the value set is configurable. The configurable options are specified.

Table A.9.3-1. Context Groups

Context Group	Default Value Set	Configurable	Use
Logical Context Identification	CID xxx \| extended CID xxx \| Private CID yyyy \| None	No\| Extensible\|Replaceable	Description of method of selection of a term from the Context Group, and identification of the IOD, Attribute, and/or Content Item that uses the term
e.g., Acquisition Protocol Equipment Settings	e.g., None	e.g., Replaceable	e.g., Value of Scheduled Protocol Code Sequence (0040,0008) from selected Modality Worklist Scheduled Procedure Step is matched to this group for protocol-assisted equipment set-up. Selected value from this group is used in Modality Performed Procedure Step Performed Protocol Code Sequence (0040,0260)
e.g., Patient Orientation	e.g., CID 19 “Patient Orientation”	e.g., No	e.g., Mapped from user console selection of Patient Orientation. Used in Patient Orientation Code Sequence (0054,0410)
...	...	...	...

The Default Value Set may be an extension of a standard context group ("extended CID xxx"). If used, a table shall be provided specifying the extended context group, the Context Group Local Version (0008,0107) value and the Context Group Creator UID (0008,010D).

This section describes the specification of any private context groups that are used. It shall follow the format for context groups specified in PS3.16.

A.9.3.2 Template Specifications

This section specifies any extensions to standard templates and/or any private templates that are used, and defines them. Definitions shall follow the format for templates specified in PS3.16

A.9.3.3 Private Code Definitions

This section specifies any private codes used and their definitions.

A.9.4 Grayscale Image Consistency

Any support for the DICOM Grayscale Standard Display Function will be specified in this section.

A.9.5 Standard Extended/Specialized/Private SOP Classes

This section describes Standard Extended SOP Class, Specialized SOP Class, or Private SOP Class that are used.

A.9.5.1 Standard Extended/Specialized/Private SOP

This section describes a particular Standard Extended SOP Class, Specialized SOP Class, or Private SOP Class.

A.9.6 Private Transfer Syntaxes

This section describes any private Transfer Syntaxes that are listed in the Transfer Syntax Tables.

A.9.6.1 Private Transfer Syntax

This section describes particular private transfer syntax. It shall follow the guidelines specified in PS3.5.

B Conformance Statement Sample Integrated Modality (Informative)

Disclaimer:

This document is an example DICOM Conformance Statement for a fictional image acquisition modality called EXAMPLE-INTEGRATED-MODALITY produced by a fictional vendor called EXAMPLE-IMAGING-PRODUCTS.

As stated in the annex title, this document is truly informative, and not normative. A conformance statement of an actual product might implement additional services and options as appropriate for its specific purpose. In addition, an actual product might implement the services described in a different manner and, for example, with different characteristics and/or sequencing of activities. In other words, this conformance statement example does not intend to standardize a particular manner that a product might implement DICOM functionality.

B.0 Cover Page

Company Name: EXAMPLE-IMAGING-PRODUCTS.

Product Name: SAMPLE INTEGRATED MODALITY

Version: 1.0-rev. A.1

Internal document number: 4226-xxx-yyy-zzz rev 1

Date: YYYYMMDD

B.1 Conformance Statement Overview

This fictional product EXAMPLE-INTEGRATED-MODALITY implements the necessary DICOM services to download work lists from an information system, save acquired RF images and associated Presentation States to a network storage device or CD-R, print to a networked hardcopy device and inform the information system about the work actually done.

Table B.1-1 provides an overview of the network services supported by EXAMPLE-INTEGRATED-MODALITY.

Table B.1-1. Network Services

SOP Classes	User of Service (SCU)	Provider of Service (SCP)
Transfer
X-Ray Radiofluoroscopic Image Storage	Yes	No
Grayscale Softcopy Presentation State	Yes	No
Workflow Management
Modality Worklist	Yes	No
Storage Commitment Push Model	Yes	No
Modality Performed Procedure Step	Yes	No
Print Management
Basic Grayscale Print Management	Option (see Note 1)	No
Presentation LUT	Option (see Note 1)	No

Note

Support for the Print Services is a separately licensable option. Details about licensable options can be found under:http://www.example-imaging-products.nocom/exampleintegrated-modality/licence-options

Table B.1-2 provides an overview of the Media Storage Application Profiles supported by Example-Integrated-Modality.

Table B.1-2. Media Services

Media Storage Application Profile	Write Files (FSC or FSU)	Read Files (FSR)
Compact Disk - Recordable
General Purpose CD-R	Yes	No

B.2 Table of Contents

A table of contents shall be provided to assist readers in easily finding the needed information.

B.3 Introduction

B.3.1 Revision History

Table B.3.1. Revision History

Document Version	Date of Issue	Author	Description
1.1	October 30, 2003	WG 6	Version for Final Text
1.2	August 30, 2007	WG 6	Revised Introduction

B.3.2 Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbreviations, References

See example text in Section A.3.

B.3.3 Additional Remarks for This Example

This document is a sample DICOM Conformance Statement created for DICOM PS3.2. It is to be used solely as an example to illustrate how to create a DICOM Conformance Statement for an acquisition modality. The subject of the document, EXAMPLE-INTEGRATED-MODALITY, is a fictional product.

B.4 Networking

B.4.1 Implementation Model

B.4.1.1 Application Data Flow

Figure B.4.1-1. Application Data Flow Diagram

The Storage Application Entity sends images and Presentation States to a remote AE. It is associated with the local real-world activity "Send Images & GSPS". "Send Images & GSPS" is performed upon user request for each study completed or for specific images selected. When activated by user's settings (auto-send), each marked set of images and associated Presentation States can be immediately stored to a preferred destination whenever a Patient/Study is closed by the user. If the remote AE is configured as an archive device the Storage AE will request Storage Commitment and if a commitment is successfully obtained will record this information in the local database.
The Workflow Application Entity receives Worklist information from and sends MPPS information to a remote AE. It is associated with the local real-world activities "Update Worklist" and "Acquire Images". When the "Update Worklist" local real-world activity is performed the Workflow Application Entity queries a remote AE for worklist items and provides the set of worklist items matching the query request. "Update Worklist" is performed as a result of an operator request or can be performed automatically at specific time intervals. When the "Acquire Images" local real-world activity is performed the Workflow Application Entity creates and updates Modality Performed Procedure Step instances managed by a remote AE. Acquisition of images will result in automated creation of an MPPS Instance. Completion of the MPPS is performed as the result of an operator action.
The Hardcopy Application Entity prints images on a remote AE (Printer). It is associated with the local real-world activity "Film Images". "Film Images" creates a print-job within the print queue containing one or more virtual film sheets composed from images selected by the user.

B.4.1.2 Functional Definition of AEs

B.4.1.2.1 Functional Definition of Storage Application Entity

The existence of a send-job queue entry with associated network destination will activate the Storage AE. An association request is sent to the destination AE and upon successful negotiation of a Presentation Context the image transfer is started. If the association cannot be opened, the related send-job is set to an error state and can be restarted by the user via job control interface. By default, the Storage AE will not try to initiate another association for this send-job automatically. However, an automatic retry (retry-timer, retrycount) can be configured by a CSE.

B.4.1.2.2 Functional Definition of Workflow Application Entity

Worklist Update attempts to download a Worklist from a remote node. If the Workflow AE establishes an Association to a remote AE, it will transfer all worklist items via the open Association. During receiving the worklist response items are counted and the query processing is canceled if the configurable limit of items is reached. The results will be displayed in a separate list, which will be cleared with the next Worklist Update.

The Workflow AE performs the creation of a MPPS Instance automatically whenever images are acquired. Further updates on the MPPS data can be performed interactively from the related MPPS user interface. The MPPS "Complete" or "Discontinued" states can only be set from the user interface.

B.4.1.2.3 Functional Definition of Hardcopy Application Entity

The existence of a print-job in the print queue will activate the Hardcopy AE. An association is established with the printer and the printer's status determined. If the printer is operating normally, the film sheets described within the print-job will be printed. Changes in printer status will be detected (e.g., out of film) and reported to the user. If the printer is not operating normally, the print-job will set to an error state and can be restarted by the user via the job control interface.

B.4.1.3 Sequencing of Real-World Activities

Figure B.4.1-2. Sequencing Constraints

Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure B.4.1-2 apply:

Query Worklist
Receive Worklist of Modality Scheduled Procedure Steps (MSPS)
Select Workitem (MSPS) from Worklist
Start acquisition and create MPPS
Acquire Images
Complete acquisition and finalize MPPS
Print acquired images (optional step)
Store acquired images and any associated Grayscale Softcopy Presentation State (GSPS) instances.
If the Image Manager is configured as an archive device the Storage AE will request Storage Commitment for the images and associated GSPS instances.

Other workflow situations (e.g., unscheduled procedure steps) will have other sequencing constraints. Printing could equally take place after the acquired images have been stored. Printing could be omitted completely if no printer is connected or hard copies are not required.

B.4.2 AE Specifications

B.4.2.1 Storage Application Entity Specification

B.4.2.1.1 SOP Classes

EXAMPLE-INTEGRATED-MODALITY provides Standard Conformance to the following SOP Classes:

Table B.4.2-1. SOP Classes for AE Storage

SOP Class Name	SOP Class UID	SCU	SCP
X-Ray Radiofluoroscopic Image Storage	1.2.840.10008.5.1.4.1.1.12.2	Yes	No
Grayscale Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.1	Yes	No
Storage Commitment Push Model	1.2.840.10008.1.20.1	Yes	No
Verification	1.2.840.10008.1.1	No	Yes

B.4.2.1.2 Association Policies

B.4.2.1.2.1 General

The DICOM standard application context name for DICOM 3.0 is always proposed:

Table B.4.2-2. DICOM Application Context for AE Storage

Application Context Name

1.2.840.10008.3.1.1.1

B.4.2.1.2.2 Number of Associations

EXAMPLE-INTEGRATED-MODALITY initiates one Association at a time for each destination to which a transfer request is being processed in the active job queue list. Only one job will be active at a time, the other remains pending until the active job is completed or failed.

Table B.4.2-3. Number of Associations Initiated for AE Storage

Maximum number of simultaneous Associations

1 (configurable)

EXAMPLE-INTEGRATED-MODALITY accepts Associations to receive N-EVENT-REPORT notifications for the Storage Commitment Push Model SOP Class.

Table B.4.2-4. Number of Associations Accepted for AE Storage

Maximum number of simultaneous Associations

5 (configurable)

B.4.2.1.2.3 Asynchronous Nature

EXAMPLE-INTEGRATED-MODALITY does not support asynchronous communication (multiple outstanding transactions over a single Association).

Table B.4.2-5. Asynchronous Nature as a SCU for AE Storage

Maximum number of outstanding asynchronous transactions

B.4.2.1.2.4 Implementation Identifying Information

The implementation information for this Application Entity is:

Table B.4.2-6. DICOM Implementation Class and Version for AE Storage

Implementation Class UID	1.xxxxxxx.yyy.etc.ad.inf.usw
Implementation Version Name	EXINTMOD_01

B.4.2.1.3 Association Initiation Policy

B.4.2.1.3.1 Activity - Send Images

B.4.2.1.3.1.1 Description and Sequencing of Activities

A user can select images and presentation states and request them to be sent to multiple destinations (up to 3). Each request is forwarded to the job queue and processed individually. When the "Auto-send" option is active, each marked instance or marked set of instances stored in database will be forwarded to the network job queue for a pre-configured auto-send target destination. Which instances will be automatically marked and the destination where the instances are automatically sent to can be configured. The "Auto-send" is triggered by the Close Patient user application.

The Storage AE is invoked by the job control interface that is responsible for processing network archival tasks. The job consists of data describing the instances marked for storage and the destination. An internal daemon process triggered by a job for a specific network destination initiates a C-STORE request to store images. If the process successfully establishes an Association to a remote Application Entity, it will transfer each marked instance one after another via the open Association. Status of the transfer is reported through the job control interface. Only one job will be active at a time. If the C-STORE Response from the remote Application contains a status other than Success or Warning, the Association is aborted and the related Job is switched to a failed state. It can be restarted any time by user interaction or, if configured, by automated retry.

The Storage AE attempts to initiate a new Association in order to issue a C-STORE request. If the job contains multiple images then multiple C-STORE requests will be issued over the same Association.

If the Remote AE is configured as an archive device the Storage AE will, after all images and presentation states have been sent, transmit a single Storage Commitment request (N-ACTION) over the same Association. Upon receiving the N-ACTION response the Storage AE will delay releasing the Association for a configurable amount of time. If no N-EVENT-REPORT is received within this time period the Association will be immediately released (i.e., notification of Storage Commitment success or failure will be received over a separate association). However, the Storage AE is capable of receiving an N-EVENT-REPORT request at any time during an association provided a Presentation Context for the Storage Commitment Push Model has been successfully negotiated (i.e., the N-ACTION is sent at the end of one association and the N-EVENT-REPORT is received during an association initiated for a subsequent send job or during an association initiated by the Remote AE for the specific purpose of sending the N-EVENT-REPORT).

Figure B.4.2-1. Sequencing of Activity - Send Images

A possible sequence of interactions between the Storage AE and an Image Manager (e.g., a storage or archive device supporting the Storage and Storage Commitment SOP Classes as an SCP) is illustrated in Figure B.4.2-1:

The Storage AE opens an association with the Image Manager
An acquired RF image is transmitted to the Image Manager using a C-STORE request and the Image Manager replies with a C-STORE response (status success).
A GSPS instance is transmitted to the Image Manager using a C-STORE request and the Image Manager replies with a C-STORE response (status success).
Another acquired RF image is transmitted to the Image Manager using a C-STORE request and the Image Manager replies with a C-STORE response (status success).
Another GSPS instance is transmitted to the Image Manager using a C-STORE request and the Image Manager replies with a C-STORE response (status success).
An N-ACTION request is transmitted to the Image Manager to obtain storage commitment of previously transmitted RF images and GSPS instances. The Image Manager replies with a N-ACTION response indicating the request has been received and is being processed.
The Image Manager immediately transmits an N-EVENT-REPORT request notifying the Storage AE of the status of the Storage Commitment Request (sent in step 6 using the N-ACTION message). The Storage AE replies with a N-EVENT-REPORT response confirming receipt. The Image Manager could send this message at any time or omit it entirely in favor of transmitting the N-EVENT-REPORT over a separate dedicated association (see note).
The Storage AE closes the association with the Image Manager.

Note

Many other message sequences are possible depending on the number of images and GSPS instances to be stored, support for Storage Commitment and when the SCP sends the N-EVENT-REPORT. The N-EVENT-REPORT can also be sent over a separate association initiated by the Image Manager (see Section B.4.2.1.4.1 on Activity - Receive Storage Commitment Response).

B.4.2.1.3.1.2 Proposed Presentation Contexts

EXAMPLE-INTEGRATED-MODALITY is capable of proposing the Presentation Contexts shown in the following table:

Table B.4.2-7. Proposed Presentation Contexts for Activity Send Images

Presentation Context Table
Abstract Syntax		Transfer Syntax		Role	Extended Negotiation
Name	UID	Name List	UID List	Role	Extended Negotiation
X-Ray Radio Fluoroscopic Image Storage	1.2.840.10008.5.1.4.1.1.12.2	Implicit VR Little Endian Explicit VR Little Endian	1.2.840.10008.1.2 1.2.840.10008.1.2.1	SCU	None
Grayscale Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.1	Implicit VR Little Endian Explicit VR Little Endian	1.2.840.10008.1.2 1.2.840.10008.1.2.1	SCU	None
Storage Commitment Push Model	1.2.840.10008.1.20.1	Implicit VR Little Endian Explicit VR Little Endian	1.2.840.10008.1.2 1.2.840.10008.1.2.1	SCU	None

Presentation Contexts for X-Ray Radio Fluoroscopic Image Storage or Grayscale Softcopy Presentation State Storage will only be proposed if the Send Job contains instances for these SOP Classes.

A Presentation Context for the Storage Commitment Push Model will only be proposed if the Remote AE is configured as an archive device.

B.4.2.1.3.1.3 SOP Specific Conformance Image & Pres State Storage SOP Classes

All Image & Presentation State Storage SOP Classes supported by the Storage AE exhibit the same behavior, except where stated, and are described together in this section.

If X-Ray Radio Fluoroscopic Image Storage SOP Instances are included in the Send Job and a corresponding Presentation Context is not accepted then the Association is aborted using AP-ABORT and the send job is marked as failed. The job failure is logged and reported to the user via the job control application.

If Grayscale Softcopy Presentation State Storage SOP Instances are included in the Send Job and a corresponding Presentation Context cannot be negotiated then Grayscale Softcopy Presentation State Storage SOP Instances will not be sent and a warning is logged. Any remaining Image Storage SOP Instances included in the Send Job will be transmitted. Failure to negotiate a Presentation Context for Grayscale Softcopy Presentation State Storage does not in itself cause the Send Job to be marked as failed. The behavior of Storage AE when encountering status codes in a C-STORE response is summarized in the Table below:

Table B.4.2-8. Storage C-STORE Response Status Handling Behavior

Service Status	Further Meaning	Error Code	Behavior
Success	Success	0000	The SCP has successfully stored the SOP Instance. If all SOP Instances in a send job have status success then the job is marked as complete.
Refused	Out of Resources	A700-A7FF	The Association is aborted using A-ABORT and the send job is marked as failed. The status meaning is logged and the job failure is reported to the user via the job control application. This is a transient failure.
Error	Data Set does not match SOP Class	A900-A9FF	The Association is aborted using A-ABORT and the send job is marked as failed. The status meaning is logged and the job failure is reported to the user via the job control application.
Error	Cannot Understand	C000-CFFF	The Association is aborted using A-ABORT and the send job is marked as failed. The status meaning is logged and the job failure is reported to the user via the job control application.
Warning	Coercion of Data Elements	B000	Image transmission is considered successful but the status meaning is logged.
Warning	Data Set does not match SOP Class	B007	Image transmission is considered successful but the status meaning is logged.
Warning	Elements Discarded	B006	Image transmission is considered successful but the status meaning is logged.
*	*	Any other status code.	The Association is aborted using A-ABORT and the send job is marked as failed. The status code is logged and the job failure is reported to the user via the job control application.

The behavior of Storage AE during communication failure is summarized in the Table below:

Table B.4.2-9. Storage Communication Failure Behavior

Exception	Behavior
Timeout	The Association is aborted using A-ABORT and the send job is marked as failed. The reason is logged and the job failure is reported to the user via the job control application.
Association aborted by the SCP or network layers	The send job is marked as failed. The reason is logged and the job failure is reported to the user via the job control application.

A failed send job can be restarted by user interaction. The system can be configured to automatically resend failed jobs if a transient status code is received. The delay between resending failed jobs and the number of retries is also configurable.

The contents of X-Ray Radio Fluoroscopic Image Storage SOP Instances created by EXAMPLE-INTEGRATED-MODALITY conform to the DICOM X-Ray Radio Fluoroscopic Image IOD definition and are described in Section B.8.1.

The contents of Grayscale Softcopy Presentation State Storage SOP Instances created by EXAMPLE-INTEGRATED-MODALITY conform to the DICOM Grayscale Softcopy Presentation State IOD and are described in Section B.8.1.

Grayscale Softcopy Presentation State Storage SOP Instances are created upon user request (e.g., explicitly via "Save" or implicitly via "Close Patient") in order to save the most recent visual appearance of an image (e.g., window center/width, shutters, graphic annotations). When saving the visual appearance, a default Presentation Label will be supplied, which the user can change. The user also has the possibility to enter a detailed Presentation Description. If multiple images from the same study are being displayed the request to save the visual appearance will create one or more Presentation States referencing all displayed images. If images from multiple studies are being displayed at least a separate Presentation State will be created for each study.

When displaying an existing image the most recently saved Grayscale Softcopy Presentation State containing references to the image will be automatically applied. The user has the option to select other Presentation States that also reference the image.

Grayscale Softcopy Presentation State Storage SOP Instances created by EXAMPLE-INTEGRATED-MODALITY will only reference instances of X-Ray Radio Fluoroscopic Image Storage SOP Instances.

Graphical annotations and shutters are only stored in Grayscale Softcopy Presentation State objects. Remote AEs that do not support the Grayscale Softcopy Presentation State Storage SOP Class will not have access to graphical annotations or shutters created by EXAMPLE-INTEGRATED-MODALITY.

B.4.2.1.3.1.4 SOP Specific Conformance for Storage Commitment SOP Class

B.4.2.1.3.1.4.1 Storage Commitment Operations (N-ACTION)

The Storage AE will request storage commitment for instances of the X-Ray Radio Fluoroscopic Image Storage SOP Class and Grayscale Softcopy Presentation State Storage SOP Class if the Remote AE is configured as an archive device and a presentation context for the Storage Commitment Push Model has been accepted.

The Storage AE will consider Storage Commitment failed if no N-EVENT-REPORT is received for a Transaction UID within a configurable time period after receiving a successful N-ACTION response (duration of applicability for a Transaction UID).

The Storage AE does not send the optional Storage Media FileSet ID & UID Attributes or the Referenced Study Component Sequence Attribute in the N-ACTION

The behavior of Storage AE when encountering status codes in a N-ACTION response is summarized in the Table below:

Table B.4.2-10. Storage Commitment N-ACTION Response Status Handling Behavior

Service Status	Further Meaning	Error Code	Behavior
Success	Success	0000	The request for storage comment is considered successfully sent. A timer is started that will expire if no N-EVENT-REPORT for the Transaction UID is received within a configurable timeout period.
*	*	Any other status code.	The Association is aborted using A-ABORT and the request for storage comment is marked as failed. The status meaning is logged and reported to the user.

The behavior of Storage AE during communication failure is summarized in the Table below:

Table B.4.2-11. Storage Commitment Communication Failure Behavior

Exception	Behavior
Timeout	The Association is aborted using A-ABORT and the send job is marked as failed. The reason is logged and the job failure is reported to the user via the job control application.
Association aborted by the SCP or network layers	The send job is marked as failed. The reason is logged and the job failure is reported to the user via the job control application.

B.4.2.1.3.1.4.2 Storage Commitment Notifications (N-EVENT-REPORT)

The Storage AE is capable of receiving an N-EVENT-REPORT notification if it has successfully negotiated a Presentation Context for the Storage Commitment Push Model (i.e., only associations established with archive devices).

Upon receipt of a N-EVENT-REPORT the timer associated with the Transaction UID will be canceled.

The behavior of Storage AE when receiving Event Types within the N-EVENT-REPORT is summarized in the Table below.

Table B.4.2-12. Storage Commitment N-EVENT-REPORT Behavior

Event Type Name	Event Type ID	Behavior
Storage Commitment Request Successful	1	The Referenced SOP Instances under Referenced SOP Sequence (0008,1199) are marked within the database as "Stored & Committed (SC) " to the value of Retrieve AE Title (0008,0054). Successfully committed SOP Instances are candidates for automatic deletion from the local database if local resources become scarce. The conditions under which automatic deletion is initiated and the amount of space freed are site configurable. SOP Instances will not be deleted if they are marked with a lock flag. The least recently accessed SOP Instances are deleted first.
Storage Commitment Request Complete - Failures Exist	2	The Referenced SOP Instances under Referenced SOP Sequence (0008,1199) are treated in the same way as in the success case (Event Type 1). The Referenced SOP Instances under Failed SOP Sequence (0008,1198) are marked within the database as "Store & Commit Failed (Sf) ". The Failure Reasons are logged and the job failure is reported to the user via the job control application. A send job that failed storage commitment will not be automatically restarted but can be restarted by user interaction.

The reasons for returning specific status codes in a N-EVENT-REPORT response are summarized in the Table below.

Table B.4.2-13. Storage Commitment N-EVENT-REPORT Response Status Reasons

Service Status	Further Meaning	Error Code	Reasons
Success	Success	0000	The storage commitment result has been successfully received.
Failure	Unrecognized Operation	0211H	The Transaction UID in the N-EVENT-REPORT request is not recognized (was never issued within an N-ACTION request).
Failure	Resource Limitation	0213H	The Transaction UID in the N-EVENT-REPORT request has expired (no N-EVENT-REPORT was received within a configurable time limit).
Failure	No Such Event Type	0113H	An invalid Event Type ID was supplied in the N-EVENT-REPORT request.
Failure	Processing Failure	0110H	An internal error occurred during processing of the N-EVENT-REPORT. A short description of the error will be returned in Error Comment (0000,0902).
Failure	Invalid Argument Value	0115H	One or more SOP Instance UIDs with the Referenced SOP Sequence (0008,1199) or Failed SOP Sequence (0008,1198) was not included in the Storage Commitment Request associated with this Transaction UID. The unrecognized SOP Instance UIDs will be returned within the Event Information of the N-EVENT-REPORT response.

B.4.2.1.4 Association Acceptance Policy

B.4.2.1.4.1 Activity - Receive Storage Commitment Response

B.4.2.1.4.1.1 Description and Sequencing of Activities

The Storage AE will accept associations in order to receive responses to a Storage Commitment Request.

Figure B.4.2-2. Sequencing of Activity - Receive Storage Commitment Response

A possible sequence of interactions between the Storage AE and an Image Manager (e.g., a storage or archive device supporting Storage Commitment SOP Classes as an SCP) is illustrated in the Figure above:

The Image Manager opens a new association with the Storage AE.
The Image Manager sends an N-EVENT-REPORT request notifying the Storage AE of the status of a previous Storage Commitment Request. The Storage AE replies with a N-EVENT-REPORT response confirming receipt.
The Image Manager closes the association with the Storage AE.

The Storage AE may reject association attempts as shown in the Table below. The Result, Source and Reason/Diag columns represent the values returned in the appropriate fields of an ASSOCIATE-RJ PDU (see Section 9.3.4 in PS3.8 ). The contents of the Source column is abbreviated to save space and the meaning of the abbreviations are:

1 - DICOM UL service-user
2 - DICOM UL service-provider (ASCE related function)
3 - DICOM UL service-provider (Presentation related function)

Table B.4.2-14. Association Rejection Reasons

Result	Source	Reason/Diag	Explanation
2 - rejected-transient	c	2 - local-limit-exceeded	The (configurable) maximum number of simultaneous associations has been reached. An association request with the same parameters may succeed at a later time.
2 - rejected-transient	c	1 - temporary-congestion	No associations can be accepted at this time due to the real-time requirements of higher priority activities (e.g., during image acquisition no associations will be accepted) or because insufficient resources are available (e.g., memory, processes, threads). An association request with the same parameters may succeed at a later time.
1 - rejected-permanent	a	2 - application-context-name-not-supported	The association request contained an unsupported Application Context Name. An association request with the same parameters will not succeed at a later time.
1 - rejected-permanent	a	7 - called-AE-title-not-recognized	The association request contained an unrecognized Called AE Title. An association request with the same parameters will not succeed at a later time unless configuration changes are made. This rejection reason normally occurs when the association initiator is incorrectly configured and attempts to address the association acceptor using the wrong AE Title.
1 - rejected-permanent	a	3 - calling-AE-title-not-recognized	The association request contained an unrecognized Calling AE Title. An association request with the same parameters will not succeed at a later time unless configuration changes are made. This rejection reason normally occurs when the association acceptor has not been configured to recognize the AE Title of the association initiator.
1 - rejected-permanent	b	1 - no-reason-given	The association request could not be parsed. An association request with the same format will not succeed at a later time.

B.4.2.1.4.1.2 Accepted Presentation Contexts

The Storage AE will accept Presentation Contexts as shown in the Table below.

Table B.4.2-15. Acceptable Presentation Contexts for Activity Receive Storage Commitment Response

Presentation Context Table
Abstract Syntax		Transfer Syntax		Role	Extended Negotiation
Name	UID	Name List	UID List	Role	Extended Negotiation
Storage Commitment Push Model	1.2.840.10008.1.20.1	Implicit VR Little Endian Explicit VR Little Endian	1.2.840.10008.1.2 1.2.840.10008.1.2.1	SCU	None
Verification	1.2.840.10008.1.1	Implicit VR Little Endian Explicit VR Little Endian	1.2.840.10008.1.2 1.2.840.10008.1.2.1	SCP	None

The Storage AE will prefer to select the Explicit VR Little Endian Transfer Syntax if multiple transfer syntaxes are offered. The Storage AE will only accept the SCU role (which must be proposed via SCP/SCU Role Selection Negotiation) within a Presentation Context for the Storage Commitment Push Model SOP Class.

B.4.2.1.4.1.3 SOP Specific Conformance for Storage Commitment SOP Class

B.4.2.1.4.1.3.1 Storage Commitment Notifications (N-EVENT-REPORT)

Upon receipt of a N-EVENT-REPORT the timer associated with the Transaction UID will be canceled.

The behavior of Storage AE when receiving Event Types within the N-EVENT-REPORT is summarized in Table B.4.2-12.

The reasons for returning specific status codes in a N-EVENT-REPORT response are summarized in Table B.4.2-13.

B.4.2.1.4.1.4 SOP Specific Conformance for Verification SOP Class

The Storage AE provides standard conformance to the Verification SOP Class as an SCP. If the C-ECHO request was successfully received, a 0000 (Success) status code will be returned in the C-ECHO response. Otherwise, a C000 (Error - Cannot Understand) status code will be returned in the C-ECHO response.

B.4.2.2 Workflow Application Entity Specification

B.4.2.2.1 SOP Classes

EXAMPLE-INTEGRATED-MODALITY provides Standard Conformance to the following SOP Classes:

Table B.4.2-16. SOP Classes for AE Workflow

SOP Class Name	SOP Class UID	SCU	SCP
Modality Worklist Information Model - FIND	1.2.840.10008.5.1.4.31	Yes	No
Modality Performed Procedure Step	1.2.840.10008.3.1.2.3.3	Yes	No

B.4.2.2.2 Association Policies

B.4.2.2.2.1 General

The DICOM standard application context name for DICOM 3.0 is always proposed:

Table B.4.2-17. DICOM Application Context for AE Workflow

Application Context Name

1.2.840.10008.3.1.1.1

B.4.2.2.2.2 Number of Associations

EXAMPLE-INTEGRATED-MODALITY initiates one Association at a time for a Worklist request.

Table B.4.2-18. Number of Associations Initiated for AE Workflow

Maximum number of simultaneous Associations

B.4.2.2.2.3 Asynchronous Nature

EXAMPLE-INTEGRATED-MODALITY does not support asynchronous communication (multiple outstanding transactions over a single Association).

Table B.4.2-19. Asynchronous Nature as a SCU for AE Workflow

Maximum number of outstanding asynchronous transactions

B.4.2.2.2.4 Implementation Identifying Information

The implementation information for this Application Entity is:

Table B.4.2-20. DICOM Implementation Class and Version for AE Workflow

Implementation Class UID	1.xxxxxxx.yyy.etc.ad.inf.usw
Implementation Version Name	EXINTMOD_01

B.4.2.2.3 Association Initiation Policy

B.4.2.2.3.1 Activity - Worklist Update

B.4.2.2.3.1.1 Description and Sequencing of Activities

The request for a Worklist Update is initiated by user interaction, i.e., pressing the buttons "Worklist Update"/"Patient Worklist Query" or automatically at specific time intervals, configurable by the user. With "Worklist Update" the automated query mechanism is performed immediately on request, while with "Patient Worklist Query" a dialog to enter search criteria is opened and an interactive query can be performed.

The interactive Patient Worklist Query will display a dialog for entering data as search criteria. When the Query is started on user request, only the data from the dialog will be inserted as matching keys into the query.

With automated worklist queries (including "Worklist Update") the EXAMPLE-INTEGRATED-MODALITY always requests all items for a Scheduled Procedure Step Start Date (actual date), Modality (RF) and Scheduled Station AE Title. Query for the Scheduled Station AE Title is configurable by a Service Engineer.

Upon initiation of the request, the EXAMPLE-INTEGRATED-MODALITY will build an Identifier for the C-FIND request, will initiate an Association to send the request and will wait for Worklist responses. After retrieval of all responses, EXAMPLE-INTEGRATED-MODALITY will access the local database to add or update patient demographic data. To protect the system from overflow, the EXAMPLE-INTEGRATED-MODALITY will limit the number of processed worklist responses to a configurable maximum. During receiving the worklist response items are counted and the query processing is canceled by issuing a C-FIND-CANCEL if the configurable limit of items is reached. The results will be displayed in a separate list, which will be cleared with the next worklist update.

EXAMPLE-INTEGRATED-MODALITY will initiate an Association in order to issue a C-FIND request according to the Modality Worklist Information Model.

Figure B.4.2-3. Sequencing of Activity - Worklist Update

A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g., a device such as a RIS or HIS that supports the Modality Worklist SOP Class as an SCP) is illustrated in the Figure above:

The Worklist AE opens an association with the Departmental Scheduler
The Worklist AE sends a C-FIND request to the Departmental Scheduler containing the Worklist Query attributes.
The Departmental Scheduler returns a C-FIND response containing the requested attributes of the first matching Worklist Item.
The Departmental Scheduler returns another C-FIND response containing the requested attributes of the second matching Worklist Item.
The Departmental Scheduler returns another C-FIND response with status Success indicating that no further matching Worklist Items exist. This example assumes that only 2 Worklist items match the Worklist Query.
The Worklist AE closes the association with the Departmental Scheduler.
The user selects a Worklist Item from the Worklist and prepares to acquire new images.

B.4.2.2.3.1.2 Proposed Presentation Contexts

EXAMPLE-INTEGRATED-MODALITY will propose Presentation Contexts as shown in the following table:

Table B.4.2-21. Proposed Presentation Contexts for Activity Worklist Update

Presentation Context Table
Abstract Syntax		Transfer Syntax		Role	Extended Negotiation
Name	UID	Name List	UID List	Role	Extended Negotiation
Modality Worklist Information Model - FIND	1.2.840.10008.5.1.4.31	Implicit VR Little Endian	1.2.840.10008.1.2	SCU	None
Modality Worklist Information Model - FIND	1.2.840.10008.5.1.4.31	Explicit VR Little Endian	1.2.840.10008.1.2.1	SCU	None

B.4.2.2.3.1.3 SOP Specific Conformance for Modality Worklist

The behavior of EXAMPLE-INTEGRATED-MODALITY when encountering status codes in a Modality Worklist C-FIND response is summarized in the Table below. If any other SCP response status than "Success" or "Pending" is received by EXAMPLEINTEGRATED-MODALITY, a message "query failed" will appear on the user interface.

Table B.4.2-22. Modality Worklist C-FIND Response Status Handling Behavior

Service Status	Further Meaning	Error Code	Behavior
Success	Matching is complete	0000	The SCP has completed the matches. Worklist items are available for display or further processing.
Refused	Out of Resources	A700	The Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged.
Failed	Identifier does not match SOP Class	A900	The Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged.
Failed	Unable to Process	C000 - CFFF	The Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged.
Cancel	Matching terminated due to Cancel request	FE00	If the query was canceled due to too may worklist items then the SCP has completed the matches. Worklist items are available for display or further processing. Otherwise, the Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query.
Pending	Matches are continuing	FF00	The worklist item contained in the Identifier is collected for later display or further processing.
Pending	Matches are continuing - Warning that one or more Optional Keys were not supported	FF01	The worklist item contained in the Identifier is collected for later display or further processing. The status meaning is logged only once for each C-FIND operation.
*	*	Any other status code.	The Association is aborted using A-ABORT and the worklist is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged.

The behavior of EXAMPLE-INTEGRATED-MODALITY during communication failure is summarized in the Table below.

Table B.4.2-23. Modality Worklist Communication Failure Behavior

Exception	Behavior
Timeout	The Association is aborted using A-ABORT and the worklist query marked as failed. The reason is logged and reported to the user if an interactive query.
Association aborted by the SCP or network layers	The worklist query is marked as failed. The reason is logged and reported to the user if an interactive query.

Acquired images will always use the Study Instance UID specified for the Scheduled Procedure Step (if available). If an acquisition is unscheduled, a Study Instance UID will be generated locally.

The Table below provides a description of the EXAMPLEINTEGRATED-MODALITY Worklist Request Identifier and specifies the attributes that are copied into the images. Unexpected attributes returned in a C-FIND response are ignored.

Requested return attributes not supported by the SCP are set to have no value. Non-matching responses returned by the SCP due to unsupported optional matching keys are ignored. No attempt is made it filter out possible duplicate entries.

Table B.4.2-24. Worklist Request Identifier

Module Name Attribute Name	Tag	VR	M	R	Q	D	IOD
SOP Common
Specific Character Set	(0008,0005)	CS		x
Scheduled Procedure Step
Scheduled Procedure Step Sequence	(0040,0100)
>Scheduled Station AET	(0040,0001)	AE	(S)			x
>Scheduled Procedure Step Start Date	(0040,0002)	DA	S			x
>Scheduled Procedure Step Start Time	(0040,0003)	TM		x		x
>Modality	(0008,0060)	CS	S	x
>Scheduled Performing Physician's Name	(0040,0006)	PN		x	x	x	x
>Scheduled Procedure Step Description	(0040,0007)	LO		x		x	x
>Scheduled Station Name	(0040,0010)	SH		x
>Scheduled Procedure Step Location	(0040,0011)	SH		x
>Scheduled Protocol Code Sequence	(0040,0008)	SQ		x			x
>Pre-Medication	(0040,0012)	LO		x		x
>Scheduled Procedure Step ID	(0040,0009)	SH		x		x	x
>Requested Contrast Agent	(0032,1070)	LO		x		x
Requested Procedure
Requested Procedure ID	(0040,1001)	SH		x	x	x	x
Requested Procedure Description	(0032,1060)	LO		x		x	x
Study Instance UID	(0020,000D)	UI		x			x
Requested Procedure Priority	(0040,1003)	SH		x
Patient Transport Arrangements	(0040,1004)	LO		x
Referenced Study Sequence	(0008,1110)	SQ		x			x
Requested Procedure Code Sequence	(0032,1064)	SQ		x			x
Imaging Service Request
Accession Number	(0008,0050)	SH		x	x	x	x
Requesting Physician	(0032,1032)	PN		x		x	x
Referring Physician's Name	(0008,0090)	PN		x	x	x	x
Visit Identification
Admission ID	(0038,0010)	LO		x
Visit Status
Current Patient Location	(0038,0300)	LO		x	x
Visit Admission
Admitting Diagnosis Description	(0008,1080)	LO		x		x
Patient Identification
Patient Name	(0010,0010)	PN		x	x	x	x
Patient ID	(0010,0020)	LO		x	x	x	x
Patient Demographic
Patient's Birth Date	(0010,0030)	DA		x	x	x	x
Patient's Sex	(0010,0040)	CS		x	x	x	x
Patient's Weight	(0010,1030)	DS		x		x	x
Confidentiality constraint on patient data	(0040,3001)	LO		x		x
Patient Medical
Patient State	(0038,0500)	LO		x		x
Pregnancy Status	(0010,21C0)	US		x		x
Medical Alerts	(0010,2000)	LO		x