DICOM 3.

0 Conformance Statement
for

DICOM Printer Version 2.0

c 2008 By Flux Inc. of Toronto, Canada
DICOM Printer

1 Conformance Statement Overview

This DICOM Conformance Statement specifies the behavior and functionality of the DICOM Printer appli-
cation. This software provides the following features:

• Storage of images and presentation states on a remote DICOM system.

• Querying for data on a remote DICOM system.

• Printing of hardcopies on a remote DICOM print SCP.

Table 1.1: Overview of the network services provided by DICOM Printer.

Name UID (SCU) (SCP)

Verification
Verification 1.2.840.10008.1.1 Yes No
Transfer
Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7 Yes No
Query / Retrieve
Patient Root Query/Retrieve Information Model 1.2.840.10008.5.1.4.1.2.1.1 Yes No
Modality Worklist Information Model - FIND 1.2.840.10008.5.1.4.31 Yes No
Print Management
Basic Grayscale Print Management (Meta) 1.2.840.10008.5.1.1.9 Yes No
Basic Color Print Management (Meta) 1.2.840.10008.5.1.1.18 Yes No

DICOM Conformance Statement Page 1

DICOM Printer

Contents
1 Conformance Statement Overview 1

2 Table of Contents 4

2 Introduction 6
2.1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Definitions, Terms and Abbrevations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Abbrevations and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Basics of DICOM Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 How to use this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Networking 12
3.1 Implementation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Application Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Functional Definitions of AE’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2.1 Find SCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2.2 Store SCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2.3 Print SCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Sequencing of Real-World Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 AE Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Find SCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1.1 SOP Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1.2 Association Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1.2.2 Number of Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1.2.3 Asychronous Nature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1.2.4 Implementation Identifying Information . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1.3 Association Initiation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1.3.1 Activity - Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.3.1.1 Description and Sequencing of Activitiesy . . . . . . . . . . . . . . . . . . . 14
3.2.1.3.1.2 Proposed Presentation Contexts . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.3.1.3 SOP Specific Conformance for Patient Root Query Retrieve Information
Model SOP Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.3.1.3.1 Optional Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.3.1.3.2 Relational Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.3.1.3.3 Extended Negotation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.3.1.3.4 Specific Character Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.3.1.3.5 Response Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.3.1.3.6 Communication Failure . . . . . . . . . . . . . . . . . . . . . . . . . . 15

DICOM Conformance Statement Page 2

DICOM Printer

3.2.1.3.1.4 SOP Specyfic Conformance for Modality Worklist Information Model -

FIND SOP Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.3.1.4.1 Optional Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1.3.1.4.2 Person Name Matching . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1.3.1.4.3 Use of Specific Character Set . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1.4 Association Acceptance Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Store SCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2.1 SOP Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2.2 Association Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2.2.2 Number of Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2.2.3 Asychronous Nature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.2.4 Implementation Identifying Information . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.3 Association Initiation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.3.1 Activity - Send Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.3.1.1 Description and Sequencing of Activities . . . . . . . . . . . . . . . . . . . 17
3.2.2.3.1.2 Proposed Presentation Contexts . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.3.1.3 SOP Specific Conformance for Secondary Capture Image Storage SOP Class 17
3.2.2.3.1.3.1 Extended Negotation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.3.1.3.2 Response Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.3.1.3.3 Communication Failure . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.4 Association Acceptance Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Print SCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3.1 SOP Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3.2 Association Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3.2.2 Number of Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3.2.3 Asychronous Nature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3.2.4 Implementation Identifying Information . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3.3 Association Initiation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3.3.1 Activity - Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3.3.1.1 Description and Sequencing of Activities . . . . . . . . . . . . . . . . . . . 20
3.2.3.3.1.2 Proposed Presentation Contexts . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3.3.1.3 SOP Specific Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3.3.1.3.1 Response Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3.3.1.3.2 Communication Failure . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3.3.1.3.3 SOP Specific Conformance for Basic Film Session SOP Class . . . . . 21
3.2.3.3.1.3.4 SOP Specific Conformance for Basic Film Box SOP Class . . . . . . . 21
3.2.3.3.1.3.5 SOP Specific Conformance for Basic Image Box SOP Class . . . . . . 21
3.2.3.4 Association Acceptance Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Physical Network Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Additional Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.3 IPv4 and IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 AE Title/Presentation Address Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

DICOM Conformance Statement Page 3

DICOM Printer

3.4.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Support of Extended Character Sets 23

5 Security 24
5.1 Security Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Association Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Application Leve Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

DICOM Conformance Statement Page 4

DICOM Printer

List of Tables
1.1 Overview of the network services provided by DICOM Printer. . . . . . . . . . . . . . . . . . 1
2.1 Revision history of the DICOM Printer software. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Abbreviations and Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Documents Referenced in this Conformance Statement. . . . . . . . . . . . . . . . . . . . . . 10
3.1 SOP Classes used by Find SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Application context name proposed by all AE’s. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Number of Associations for Find SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 DICOM implementation class and version for all AE’s. . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Proposed presentation context for Find SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Find SCU DICOM Command Response Status Handling Behaviour. . . . . . . . . . . . . . . 15
3.7 Find SCU DICOM Command Communication Failure Behaviour. . . . . . . . . . . . . . . . . 15
3.8 SOP Classes used by Store SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.9 Number of Associations for Store SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.10 Proposed presentation context for Store SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.11 Store SCU DICOM Command Response Status Handling Behaviour. . . . . . . . . . . . . . . 18
3.12 Store SCU DICOM Command Communication Failure Behaviour. . . . . . . . . . . . . . . . 19
3.13 SOP Classes used by Print SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.14 Number of Associations for Print SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.15 Proposed presentation context for Print SCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.16 Print SCU DICOM Command Response Status Handling Behaviour. . . . . . . . . . . . . . . 20
3.17 Print SCU DICOM Command Communication Failure Behaviour. . . . . . . . . . . . . . . . 21
3.18 Configuration Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

DICOM Conformance Statement Page 5

DICOM Printer

2 Introduction
Flux DICOM Printer (FDP) is a DICOM enabler, designed to fit into existing healthcare network infrastruc-
ture and add DICOM-compliant query and storage functionality to devices that presently lack this capability.
As such, FDP permits the querying of remote data and associated remote storage of printed documents and
images on an existing PACS. For this purpose, FDP utilizes the DICOM 3.0 protocol to perform both query
and store operations against compliant devices.

2.1 Revision History

See Table 2.1.

Table 2.1: Revision history of the DICOM Printer software.

Version Date Changes

2.0 Beta 2008.08.16 First revision
2.0.0 2008.10.31 Implemented suspension for all AEs and added Modality Worklist
Information Model - FIND support

2.2 Audience
This document is written for the people that need to understand how FDP 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.

2.3 Remarks
The scope of this DICOM Conformance Statement is to facilitate integration between FDP 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 be-
tween 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 intercon-
nectivity and interoperability between the product and other DICOM conformant equipment.

DICOM Conformance Statement Page 6

DICOM Printer

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

2.4 Definitions, Terms and Abbrevations

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

Abstract Syntax The information that is to be exchanged between applications, generally equivalent to
a Service/Object Pair (SOP) Class. Examples: Verification SOP lass, Modality Worklist Information
Model Find SOP Class, and 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 he 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 informa-
tion may be a complex data structure (Sequence) composed of lower level data elements. Examples:
Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation (0028,0004), and
Procedure Code Sequence (0008,1032).
Information Object Definition (IOD) The specified set of Attributes that comprise a type of data ob-
ject; does not represent a specific instance of the data object, but rather a class of similar data objects
that have the same properties. The Attributes may be specified as Mandatory (Type 1), required but
possibly unknown (Type 2), or Optional (Type 3), and there may be conditions associated with the
use of an Attribute (Types 1C and 2C). Examples: MR Image IOD, CT Image IOD, Print Job IOD.
Joint Photographic Experts Group (JPEG) A set of standardized image compression techniques, avail-
able 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 Attributes within an Information Object Definition that are logically related to each other.
Example: Patient Module includes Patient Name, Patient ID, Patient Birth Date, and Patient Sex.
Negotiation First phase of Association establishment that allows Application Entities to agree on the types
of data to be exchanged and how that data will be encoded.
Presentation Context The set of DICOM network services used over an Association, as negotiated be-
tween Application Entities; includes Abstract Syntaxes and Transfer Syntaxes.

DICOM Conformance Statement Page 7

DICOM Printer

Protocol Data Unit (PDU) A packet (piece) of a DICOM message sent across the network. Devices
must specify the maximum size packet they can receive for DICOM messages.

Security Profile A set of mechanisms, such as encryption, user authentication, or digital signatures, used
by an Application Entity to ensure confidentiality, integrity, and/or availability of exchanged DICOM
data.

Service Class Provider (SCP) Role of an Application Entity that provides a DICOM network service;
typically, a server that performs operations requested by another Application Entity (Service Class
User). Examples: Picture Archiving and Communication System (image storage SCP, and image
query/retrieve SCP), Radiology Information System (modality worklist SCP).
Service Class User (SCU) Role of an Application Entity that uses a DICOM network service; typically,
a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging
workstation (image query/retrieve SCU).

Service/Object Pair (SOP) Class The specification of the network or media transfer (service) of a par-
ticular 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 ex-
changed 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:
JPEG compressed (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.

2.4.2 Abbrevations and Acronyms

TODO: This shouldn’t be longtable but a simple tabular. When the contents of the document is finished,
get rid of unused acronyms.

Table 2.2: Abbreviations and Acronyms.

Abbreviation or Acronym Definition

DICOM Conformance Statement Page 8

DICOM Printer

Abbreviation or Acronym Definition

AE Application Entity
CDA Clinical Document Architecture
CD-R Compact Disk Recordable
CR Computed Radiography
CT Computed Tomography
DHCP Dynamic Host Configuration Protocol
DICOM Digital Imaging and Communications in Medicine
DIT Directory Information Tree (LDAP)
DNS Domain Name System
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
JPEG Joint Photographic Experts Group
LUT Look-up Table
MTU Maximum Transmission Unit (IP)
MWL Modality Worklist
OSI Open Systems Interconnection
PACS Picture Archiving and Communication System
PDU Protocol Data Unit
RIS Radiology Information System
SC Secondary Capture
SCP Service Class Provider
SCU Service Class User
SOP Service-Object Pair
SPS Scheduled Procedure Step
TCP/IP Transmission Control Protocol/Internet Protocol

2.5 References
The following documents are referenced in this conformance statement:

DICOM Conformance Statement Page 9

DICOM Printer

Table 2.3: Documents Referenced in this Conformance Statement.

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

2.6 Basics of DICOM Communication

This section describes terminology used in this Conformance Statement for the non-specialist. The key
terms used in the Conformance Statement are highlighted in italics below. 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 combina-
tions 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. The receiver explicitly acknowledges each transfer 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.

2.7 How to use this document

This Conformance Statement consists of the following chapters:
3: Networking Consists of two main sections:

3.1: Implementation Model The first section describes the Implementation Model. It explains the
functional relation between the device and the DICOM services. A DICOM service is implemented

DICOM Conformance Statement Page 10

DICOM Printer

on a device by a software process, which is called an “Application Entity” (AE). Each AE has
a unique name called the “AE Title” which is used to identify it to other AEs. The AE Title
is configurable to avoid two devices with the same name on a network. The “bubble diagram”
(Application Data Flow Diagram) shows the interaction of the AE with the outside world across
the dashed line, i. e. the DICOM interface. This Application Data Flow Diagram depicts
graphically the relationship of the DICOM AE with local functions at the workstation as well as
the relationship with external activities. One should compare this implementation model and its
description with the model of the other devices that the DICOMscope software will connect to in
order to determine connectivity.
3.2: AE Specifications Each AE supports one or more Service Object Pair (SOP) classes. A SOP
class consists of a combination of an object or information model with specific DICOM services.
An example of such a SOP class is the CT Image Storage Class, which consists of the combination
of the DICOM C STORE command with the CT image object. Each of these classes is uniquely
identified by an Identification number (UID), which is issued by the NEMA. The role of the AE is
specified, which can be a client or server (compare with a speaker or listener). In DICOM terms,
this is called a Service Class User or Service Class Provider (SCU or SCP). In order to interconnect
with another device, the SOP classes as well as their role (SCU or SCP) have to be matched,
i. e. a SCU has to match a SCP at another device with an identical SOP class. Make sure to
compare the UID itself, not the description because there are SOP classes which have the same
name, but support a different (newer) object. Each SOP class supports a particular presentation
context which is the combination of the SOP Class and the transfer syntax. The transfer syntax
defines the encoding of the DICOM basic elements, i. e. its attributes and how the data is
represented. The encoding of the data type, or Value Representation (VR), can be done in two
ways – implicitly or explicitly. Explicit VR means that the transmitted data will include the VR
information along with data and attribute tags. Implicit VR means the VR information will not
be included, and the receiving application must determine the VR type from the Attribute Tag.
In addition, the data can be communicated in the Little Endian (Intel) or Big Endian (Motorola,
Sparc, MIPS) byte ordering. This means that for certain 16 bit words, the two 8 bit bytes might
have to be swapped to be able to interpret the information by a different device. The transfer
syntax of two devices have to match in order to communicate.

4: Support of Extended Character Sets DICOM supports a large number of character sets, including
ASCII (the default), some of the ISO 8859 character sets for use with most European languages and a
number of character sets for use in the Far East. This section of the conformance statement specifies
the character sets that an implementation actually supports. The supported character sets should be
compared carefully if extended character sets are to be used, since the inability of a system to handle
extended characters might affect the way names and identifiers can be entered, displayed, queried etc.

DICOM Conformance Statement Page 11

DICOM Printer

3 Networking
3.1 Implementation model
3.1.1 Application Flow Diagram

3.1.2 Functional Definitions of AE’s

3.1.2.1 Find SCU
The user activates Find SCU in order to query for matching studies or worklist against one or more remote
AEs. Requests are always handled synchronously.

3.1.2.2 Store SCU

Store SCU is initiated by the user, and activated in the background, always synchronously, when the user
requests that images to be sent to a remote AE, which is selected from a configured list. Store SCU will only
make a single attempt at association; if it fails, then another user request is required to commence another
attempt.

3.1.2.3 Print SCU

Print SCU is an application entity that implements the DICOM Print Management Service Class as an SCU.
The user activates PRINT SCU when a request to produce a hardcopy is made. When the user requests a
print to a particular printer, PRINT SCU attempts to spool the print job. If DICOM Printer is terminated,
the print job will continue to be transmitted until it is completed or aborted.

3.1.3 Sequencing of Real-World Activities

All activities occur in the sequnce defined by user in configuration file. However, in a typical use, Query will
precede store or print, and the later two are generally mutually exclusive.

3.2 AE Specifications
3.2.1 Find SCU
3.2.1.1 SOP Classes
This application entity provides standard conformance to the DICOM SOP class given in Table 3.1.

3.2.1.2 Association Policies

3.2.1.2.1 General
The DICOM standard application context name, which is always proposed, is given in Table 3.2.

DICOM Conformance Statement Page 12

DICOM Printer

Table 3.1: SOP Classes used by Find SCU.

Name UID (SCU) (SCP)

Patient Root Query/Retrieve Information Model 1.2.840.10008.5.1.4.1.2.1.1 Yes No
Modality Worklist Information Model - FIND 1.2.840.10008.5.1.4.31 Yes No

Table 3.2: Application context name proposed by all AE’s.

Application Context Name 1.2.840.10008.3.1.1.1

3.2.1.2.2 Number of Associations

Find SCU will only propose a single association. See Table 3.3.

Table 3.3: Number of Associations for Find SCU.

Maximum number of simultaneous Associ- 1

ations

3.2.1.2.3 Asychronous Nature

Find SCU will only allow a single outstanding operation on an Association. Therefore, Find SCU will not
perform asynchronous operations window negotiation.

3.2.1.2.4 Implementation Identifying Information

See Table 3.4.

Table 3.4: DICOM implementation class and version for all AE’s.

Implementation Class UID 1.2.826.0.1.3680043.2.1635.0.1.0.1

Implementation Version Name FLUX DICOM 101

3.2.1.3 Association Initiation Policy

Find SCU attempts to initiate a new association when while perfoming user-defined workflow, processed job
reaches query action.

DICOM Conformance Statement Page 13

DICOM Printer

3.2.1.3.1 Activity - Query

3.2.1.3.1.1 Description and Sequencing of Activitiesy
A single attempt will be made to query the remote AE. If the query fails, for whatever reason, the query
will be suspended for some time or discarded. The actual behaviour depends on user who specifies error
handling strategy inside configuration file.

3.2.1.3.1.2 Proposed Presentation Contexts

The default behavior of the Print SCU is to propose for each of the supported SOP classes a single presen-
tation context containing transfer syntaxes given in Table 3.5.

Table 3.5: Proposed presentation context for Find SCU.

Abstract Syntax Transfer Syntax Extendent

Role
Name UID Name UID Negotiation
See Table 3.1 See Table 3.1 Implicit VR Little Endian 1.2.840.10008.1.2 SCU None
Explicit VR Little Endian 1.2.840.10008.1.2.1 SCU None
Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None

3.2.1.3.1.3 SOP Specific Conformance for Patient Root Query Retrieve Information Model
SOP Class
Find SCU supports queries against all levels of Patient Root Query/Retrieve Information Model, i.e:

• Patient.

• Study.

• Series.

• Composite Object Instance.

However, the default query level is the Study and without explicit user declaration inside configuration file
this one will be used.

3.2.1.3.1.3.1 Optional Keys

Find SCU supports all avaliable Optional Keys at each level of the SOP Class. To get the full list of
attributes, please see PS3.4.C.6.1.1.2-5.

3.2.1.3.1.3.2 Relational Queries

Find SCU does not generate relational queries.

DICOM Conformance Statement Page 14

DICOM Printer

3.2.1.3.1.3.3 Extended Negotation

Find SCU does not support extended negotation of combined date-time matching and/or fuzzy semantic
matching of person names.

3.2.1.3.1.3.4 Specific Character Set

Find SCU does not make use of Specific Character Set when encoding queries and interpreting responses.

3.2.1.3.1.3.5 Response Behaviour

See Table 3.6.

Table 3.6: Find SCU DICOM Command Response Status Handling Behaviour.

Service Further Error

Behaviour
Status Meaning Code
Success — 0000 The query request is considered succesully finished, i.e. all match-
ing identifiers has been succesfully retrieved.
Pending — FE0* The query request is considered being evaulated. The service will
retrieve response identifier and continue sending C-FIND request.
Failure — Other The service will abort association. The status meaning will be
logged and reported to the user.

3.2.1.3.1.3.6 Communication Failure

See Table 3.7.

Table 3.7: Find SCU DICOM Command Communication Failure Behaviour.

Exception Behaviour
Timeout The Association is aborted using A-ABORT and the query is
marked as failed. The reason is logged and the job failure is
reported to the user via the log file.

Association aborted by the SCP The query is marked as failed. The reason is logged and the job
or network layers failure is reported to the user via the log file.

3.2.1.3.1.4 SOP Specyfic Conformance for Modality Worklist Information Model - FIND SOP
Class

DICOM Conformance Statement Page 15

DICOM Printer

3.2.1.3.1.4.1 Optional Keys

Find SCU may request matching on Optional Matching Key Attrbutes but only those which are not a
part of any Sequence of Items. There is no arbitrary list of these attributes – the user provide one inside
configuration file. Find SCU does not request Type 3 Return Key Attributes and supports none Templates
for Protocol Context Sequence.

3.2.1.3.1.4.2 Person Name Matching

Find SCU does not support extendent negotiation of fuzzy semantic matching of person names.

3.2.1.3.1.4.3 Use of Specific Character Set

Find SCU does not make use of Specific Character Set (0008,0005) when encoding queries and interpreting
responses.

3.2.1.4 Association Acceptance Policy

Find SCU does not accept associations.

3.2.2 Store SCU

3.2.2.1 SOP Classes
This application entity provides standard conformance to the DICOM SOP classes given in Table 3.8.

Table 3.8: SOP Classes used by Store SCU.

Name UID (SCU) (SCP)

Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7 Yes No

3.2.2.2 Association Policies

3.2.2.2.1 General
The DICOM standard application context name, which is always proposed, is given in Table 3.2.

3.2.2.2.2 Number of Associations

Store SCU will only propose a single association. See Table 3.9.

Table 3.9: Number of Associations for Store SCU.

Maximum number of simultaneous Associ- 1

ations

DICOM Conformance Statement Page 16

DICOM Printer

3.2.2.2.3 Asychronous Nature

Store SCU will only allow a single outstanding operation on an Association. Therefore, Store SCU will not
perform asynchronous operations window negotiation.

3.2.2.2.4 Implementation Identifying Information

See Table 3.4.

3.2.2.3 Association Initiation Policy

Store SCU attempts to initiate a new association when while perfoming user-defined workflow, processed
job reaches store action.

3.2.2.3.1 Activity - Send Images

3.2.2.3.1.1 Description and Sequencing of Activities
A single attempt will be made to store image contents in the remote AE. If the operation fails, the Store
SCU may attempt to retry operation after being suspended for some time or abort it. The actual behaviour
depends on user, who specifies that in configuration file.

3.2.2.3.1.2 Proposed Presentation Contexts

The default behavior of the Store SCU is to propose for each of the supported SOP classes a single presen-
tation context containing the transfer syntaxes given in one of groups listed in Table 3.10. Particuliar group
is determined by user’s declaration inside configuration file.

3.2.2.3.1.3 SOP Specific Conformance for Secondary Capture Image Storage SOP Class
3.2.2.3.1.3.1 Extended Negotation
Find SCU does not support extended negotation.

3.2.2.3.1.3.2 Response Behaviour

See Table 3.11.

3.2.2.3.1.3.3 Communication Failure

See Table 3.12.

3.2.2.4 Association Acceptance Policy

Store SCU does not accept associations.

3.2.3 Print SCU

3.2.3.1 SOP Classes
This application entity provides standard conformance to the DICOM SOP classes given in Table 3.13.

DICOM Conformance Statement Page 17

DICOM Printer

Table 3.10: Proposed presentation context for Store SCU.

Abstract Syntax Transfer Syntax Extendent

Role
Name UID Name UID Negotiation
See Table 3.8 See Table 3.8 Implicit Little Endian 1.2.840.10008.1.2 SCU None
Explicit Little Endian 1.2.840.10008.1.2.1 SCU None
Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None
See Table 3.8 See Table 3.8 Implicit Little Endian 1.2.840.10008.1.2 SCU None
Explicit Little Endian 1.2.840.10008.1.2.1 SCU None
Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None
RLE Compression 1.2.840.10008.1.2.5 SCU None
See Table 3.8 See Table 3.8 Implicit Little Endian 1.2.840.10008.1.2 SCU None
Explicit Little Endian 1.2.840.10008.1.2.1 SCU None
Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None
JPEG lossy 1.2.840.10008.1.2.4.51 SCU None
See Table 3.8 See Table 3.8 Implicit Little Endian 1.2.840.10008.1.2 SCU None
Explicit Little Endian 1.2.840.10008.1.2.1 SCU None
Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None
JPEG lossless 14 SV1 1.2.840.10008.1.2.4.70 SCU None

Table 3.11: Store SCU DICOM Command Response Status Handling Behaviour.

Service Further Error

Behaviour
Status Meaning Code
Success — 0000 The store request is considered succesully finished and job is
marked as completed.
Warning — B00* Image transmission is considered succesfull but the status mean-
ing is logged.
Failure — Other The service will abort association. The status meaning will be
logged and reported to the user.

3.2.3.2 Association Policies

3.2.3.2.1 General
The DICOM standard application context name, which is always proposed, is given in Table 3.2.

DICOM Conformance Statement Page 18

DICOM Printer

Table 3.12: Store SCU DICOM Command Communication Failure Behaviour.

Exception Behaviour
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 log file.
Association aborted by the SCP The send job is marked as failed. The reason is logged and the
or network layers job failure is reported to the user via the log file.

Table 3.13: SOP Classes used by Print SCU.

Name UID (SCU) (SCP)

Basic Grayscale Print Management Meta 1.2.840.10008.5.1.1.9 Yes No
Basic Color Print Management Meta 1.2.840.10008.5.1.1.18 Yes No

3.2.3.2.2 Number of Associations

Print SCU will only propose a single association. See Table 3.14.

Table 3.14: Number of Associations for Print SCU.

Maximum number of simultaneous Associ- 1

ations

3.2.3.2.3 Asychronous Nature

Print SCU will only allow a single outstanding operation on an Association. Therefore, Store SCU will not
perform asynchronous operations window negotiation.

3.2.3.2.4 Implementation Identifying Information

See Table 3.4.

3.2.3.3 Association Initiation Policy

Print SCU attempts to initiate a new association when while perfoming user-defined workflow, processed job
reaches store action.

3.2.3.3.1 Activity - Print

DICOM Conformance Statement Page 19

DICOM Printer

3.2.3.3.1.1 Description and Sequencing of Activities

A single attempt will be made to print image contents on the remote AE. If the operation fails, Find SCU
may suspend the operation and attend to retry it after some time or just abort it. The actual behaviour
depends on provided by user configuration file.

3.2.3.3.1.2 Proposed Presentation Contexts

The default behavior of the Print SCU is to propose for each of the supported SOP classes a single presen-
tation context containing the transfer syntaxes given in Table 3.15.

Table 3.15: Proposed presentation context for Print SCU.

Abstract Syntax Transfer Syntax Extendent

Role
Name UID Name UID Negotiation
See Table 3.13 See Table 3.13 Implicit Little Endian 1.2.840.10008.1.2 SCU None
Explicit Little Endian 1.2.840.10008.1.2.1 SCU None
Explicit VR Big Endian 1.2.840.10008.1.2.2 SCU None

3.2.3.3.1.3 SOP Specific Conformance

Following behaviour is applicable to all supported SOP Classes.

3.2.3.3.1.3.1 Response Behaviour

See Table 3.16.

Table 3.16: Print SCU DICOM Command Response Status Handling Behaviour.

Service Further Error

Behaviour
Status Meaning Code
Success — 0000 The request is considered succesully finished.
Warning — B0** The request is considered succesfull but the status meaning is
logged.
Failure — Other The service will abort association. The status meaning will be
logged and reported to the user.

3.2.3.3.1.3.2 Communication Failure

See Table 3.17.

DICOM Conformance Statement Page 20

DICOM Printer

Table 3.17: Print SCU DICOM Command Communication Failure Behaviour.

Exception Behaviour
Timeout The Association is aborted using A-ABORT and the query is
marked as failed. The reason is logged and the job failure is
reported to the user via the log file.

Association aborted by the SCP The query is marked as failed. The reason is logged and the job
or network layers failure is reported to the user via the log file.

3.2.3.3.1.3.3 SOP Specific Conformance for Basic Film Session SOP Class
Print SCU uses two DIMSE Service Elements:

• N-CREATE,

• N-ACTION.

Optional attributes for N-CREATE are those belonging to Basic Film Session Presentation Module and they
are listed in PS3.3.C.13.1.

3.2.3.3.1.3.4 SOP Specific Conformance for Basic Film Box SOP Class
Print SCU uses only N-CREATE DIMSE Service Element. Optional attributes for N-CREATE are those
belonging to Basic Film Box Presentation Module and they are listed in PS3.3.C.13.3.

3.2.3.3.1.3.5 SOP Specific Conformance for Basic Image Box SOP Class
Print SCU uses only N-SET DIMSE Service Element. Optional attributes for N-SET are those belonging to
Basic Image Box Presentation Module and they are listed in PS3.3.C.13.5.

3.2.3.4 Association Acceptance Policy

Print SCU does not accept associations.

3.3 Network Interfaces

3.3.1 Physical Network Interface
The application is indifferent to the physical medium over which TCP/IP executes; which is dependent on
the underlying operating system and hardware.

3.3.2 Additional Protocols

No additional protocols are supported.

DICOM Conformance Statement Page 21

DICOM Printer

3.3.3 IPv4 and IPv6 Support

This product supports both IPv4 and IPv6. It does not utilize any of the optional configuration identification
or security features of IPv6.

3.4 Configuration
3.4.1 AE Title/Presentation Address Mapping
The Calling AE Title of the local application is configurable in the configuration file. The mapping of
the logical name by which remote AEs are described to Called AE Titles as well as presentation address
(hostname or IP address and port number) is also configurable in this file.

3.4.2 Parameters
See Table 3.18.

Table 3.18: Configuration Parameters.

Parameter Configurable Default Value

General Parameters
PDU Size Yes 16 KB
Time-out waiting for acceptance or rejection Response Yes 1s
to an Association Open Request. (Application Level
timeout)
General DIMSE level time-out values Yes 1s
Time-out waiting for response to TCP/IP connect() No None
request. (Low-level timeout)
Time-out waiting for acceptance of a TCP/IP message No None
over the network. (Low-level timeout)
Time-out for waiting for data between TCP/IP pack- No None
ets. (Low-level timeout)
Any changes to default TCP/IP settings, such as con- No None
figurable stack parameters.
AE Specific Parameters (all AE’s)
Size constraint in maximum object size No None
Maximum PDU size the AE can send No Unlimited
AE specific DIMSE level time-out values Yes 1s
Transfer Syntax support Yes All proposed
Other parameters that are configurable No None

DICOM Conformance Statement Page 22

DICOM Printer

4 Support of Extended Character Sets

The application supports only ISO IR 100 (ISO 8859-1 Latin 1) as extended character set.

DICOM Conformance Statement Page 23

DICOM Printer

5 Security
It is assumed that FDP is used within a secured environment. It is assumed that a secured environment
includes at a minimum:

• Firewall or router protections to ensure that only approved external hosts have network access to FDP.

• Firewall or router protections to ensure that FDP only has network access to approved external hosts.
• Any communication with external hosts and services outside the locally secured environment use ap-
propriate secure network channels (e.g. such as a Virtual Private Network (VPN)).

Other network security procedures such as automated intrusion detection may be appropriate in some envi-
ronments. Additional security features may be established by the local security policy and are beyond the
scope of this conformance statement.

5.1 Security Profiles

None supported.

5.2 Association Level Security

None supported.

5.3 Application Leve Security

None supported.

DICOM Conformance Statement Page 24