Dicompass 3.0 conformance statement

Conformance statement overview

Dicompass is DICOM 3.0 compliant modular viewer, that is able to:

view most of commonly used image DICOM classes
view and generate structured reports
view and edit radiotherapeutical structures and contours
retrive images from other Dicom compliant devices
print images or series on common or DICOM compatible printer

Table 1. Supported Networking DICOM Service
SOP Classes	User of Service (SCU)	Provider of Service (SCP)
Transfer
CT Image Storage	yes	yes
Secondary Capture Image Storage	yes	yes
Ultrasound Image Storage	yes	yes
Computed Radiography Image Storage	yes	yes
Digital X-Ray Image Storage - For Presentation	yes	yes
Digital Mammography X-Ray Image Storage - For Presentation	yes	yes
MR Image Storage	yes	yes
X-Ray Angiographic Image Storage	yes	yes
X-Ray Radiofluoroscopic Image Storage	yes	yes
Nuclear Medicine Image Storage	yes	yes
VL Endoscopic Image Storage	yes	yes
VL Microscopic Image Storage	yes	yes
VL Slide-Coordinates Microscopic Image Storage	yes	yes
VL Photographic Image Storage	yes	yes
Positron Emission Tomography Image Storage	yes	yes
Enhanced CT Image Storage	yes	yes
Enhanced MR Image Storage	yes	yes
Enhanced PET Image Storage	yes	yes
MR Spectroscopy Storage	yes	yes
Video Endoscopic Image Storage	yes	yes
Video Microscopic Image Storage	yes	yes
Video Photographic Image Storage	yes	yes
RT Image Storage	yes	yes
RT Plan Storage	yes	yes
RT Dose Storage	yes	yes
RT Structure Set Storage	yes	yes
Siemens CSA Non-Image Storage	yes	yes
RT Beams Treatment Record Storage	yes	yes
RT Brachy Treatment Record Storage	yes	yes
RT Treatment Summary Record Storage	yes	yes
Storage commitment
Storage Commitment Push Model	yes	no
Query / retrieve
Patient Root Query/Retrieve Information Model - FIND	yes	no
Patient Root Query/Retrieve Information Model - MOVE	yes	no
Patient Root Query/Retrieve Information Model - GET	yes	no
Study Root Query/Retrieve Information Model - FIND	yes	no
Study Root Query/Retrieve Information Model - MOVE	yes	no
Study Root Query/Retrieve Information Model - GET	yes	no
Workflow management
Modality Worklist Information Model - FIND	yes	no
Modality Performed Procedure Step SOP Class	yes	no
Print management
Basic Color Print Management Meta SOP Class	yes	no
Basic Grayscale Print Management Meta SOP Class	yes	no

Table 2. Supported Media Storage Application Profiles
Media Storage Application Profile	Write Files (FSC or FSU)	Read Files (FSR)
Compact Disk - Recordable
General Purpose CD-R	yes	yes
General Purpose CD-RW	yes	ye
DVD
General Purpose DVD-R	yes	yes
General Purpose DVD+R	yes	yes
General Purpose DVD-RW	yes	yes
General Purpose DVD-RAM	yes	yes

Introduction

The Dicompass is multiplatform modular DICOM viewer implemented in Java. Its able to run on Windows 2000, XP, 2003, Vista, 7 and 8, Linux and with some limitation on Mac OS X.

Audience

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

Remarks

The scope of this DICOM Conformance Statement is to facilitate integration between Dicompass 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.

Terms and definitions

Informal definitions are provided for the following terms used in this Conformance Statement. The DICOM Standard is the authoritative source for formal definitons 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 Attributes that comprise a type of data object; does not represent a specific instance of the data object, but rather a class of similar data objects that have the same properties. 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, 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 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 between Application Entities; includes Abstract Syntaxes and 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 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) ofa 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: JPEG compressed (images), little endian explicit value representation.
Unique Identifier (UID): a globally unique 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.

Basic 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 intial 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 specifes a number of network services and types of information objects, each of which is called an Abstract Syntax for the Negotiation. DICOM also specifes 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.

Abbreviations

AE	Application Entity
AET	Application Entity Title
CD-R	Compact Disk Recordable
CR	Computed Radiography
CT	Computed Tomography
DHCP	Dynamic Host Configuration Protocol
DICOM	Digital Imaging and Communications in Medicine
DNS	Domain Name System
DX	Digital X-ray
FSC	File-Set Creator
FSU	File-Set Updater
FSR	File-Set Reader
HIS	Hospital Information System
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
LUT	Look-up Table
MPEG	Moving Picture Experts Group
MG	Mammography (X-ray)
MPPS	Modality Performed Procedure Step
MR	Magnetic Resonance Imaging
MSPS	Modality Scheduled Procedure Step
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)
RF	Radiofluoroscopy
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)
US	Ultrasound
VL	Visible Light
VR	Value Representation
XA	X-ray Angiography

Implementation model

The Dicompass is divided into several modules. Dependencies of modules are visualised within figure Dicompass modules. Functions of each module is described in table below. Each module is stored in source code package with low dependency which allows to separate functionality even on source code level. Functionality of an application can vary on each instalation according to loaded modules. Inter-module dependency graph does not contain any cycle. Any module can be removed by removing all its subtree.

Figure 1. Dicompass modules

Table 3. Modules description
Module name	functionality description
config	set of classes for global application configuration
core	set of general purpose and reusable classes sorted into thematically closed subpackages (ie. dicom, security, video…)
server	classes for communication with DicomServer
impl	application of core classes, common UI dialogs (ie. MainForm, ConfigForm…)
general	contains standard viewer functions which are available in free version (like viewing, data management…)
advanced	contains functions that are available in advanced registered browser
grabber	digitalization and dicomization related classes
diagnostic	diagnostic station related class (MPR, MIP, OpenGL…)

Application Data Flow

Figure Application Data Flow describes how Dicompass communicates with other application entities.

Figure 2. Application Data Flow

Functional definitions of AE’s

The Dicompass waits for another DICOM application to connect on all local IP addresses and port specified in Dicompass configuration panel. Listening thread is ready to response for verification messages and to accept c-store requests (if passive DICOM retrieving is enabled by license file or if query / retrieve is in progress).

The Dicompass can also initiate connection to other AEs in cases of:

performing query / retrieve
printing on DICOM printer
quering Modality worklist
creating / updating Modality Performed Procedure Step (MPPS)

Besides DICOM associations Dicompass is also capable of initiation HTTPS connection to DicomShare or DEX server whose can be used as gate to remote PACS server. Dicompass also communicates with HL7 servers for purpose of creating Modality Worklists (if enabled by license).

AE specification

The Dicompass Application Entity provides Standard Conformance to all SOP Classes as listed in Conformance Statement Overview in table Supported Networking DICOM Service.

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

Associations policies

General

The Dicompass will establish association to all DICOM requests whose abstract Syntax and Transfer Syntax are determined valid.

The DICOM Application Context Name (ACN) which is always proposed is:

Table 4. DICOM application context
Application Context Name	1.2.840.10008.3.1.1.1

Number of associations

Each association is processed in separate thread.

Table 5. Number of Associations as an association initiator
Maximum number of simultaneous associations	5

Table 6. Number of Associations as an association acceptor
Maximum number of simultaneous associations	5

Asynchronous Nature

The Dicompass does not support asynchronous communication. Multiple outstanding transactions are not supported. It allows up to one invoked and one performed operation on an Association (it is synchronous). Asynchronous mode of operation is not supported.

Table 7. Asynchronous Nature as an Association initiator
Maximum number of outstanding asynchronous transactions	1

Implementation Identifying Information

Table 8. DICOM Implementation Class and Version
Implementation Class UID	1.2.40.0.13.1.1
Implementation Version Name	dcm4che-3.2

Functional Definitions of AE’s

ECHO-SCP

ECHO-SCP waits in the background for connections, will accept associations with Presentation Contexts for SOP Class of the Verification Service Class, and will respond successfully to echo requests.

STORAGE-SCP

STORAGE-SCP waits in the background for connections, will accept associations with Presentation Contexts for SOP Classes of the Storage Service Class, and will store the received instances to the local database where they may subsequently be listed and viewed through the user interface.

STORAGE-SCP is active only when dicomstore module is loaded and started, or when there is active retrieve after query. When dicomstore module is not loaded or started and there is no active retrieve after query, every association with store request is ''rejected'' (REJECTED_PERMANENT, SOURCE_SERVICE_USER, REASON_NO_REASON_GIVEN).

STORAGE-SCU

STORAGE-SCU is activated through the user interface when a user selects instances from the local database or a DICOMDIR, or the currently loaded instances, and requests that they be sent to a remote AE (selected from a pre-configured list or directly entered in format AET@host:port). Remote AE can be also selected via ePACS[http://www.epacs.cz/] XML directory.

STORAGE-SCU is also activated after an user performs digitalization or dicomization and confirms storage to remote AE.

Store operation is not blocking operation and is running on background.

FIND-SCU

FIND-SCU is activated through the user interface when a user selects a remote AE to query (from a pre-configured list or directly entered remote AE address in format AET@host:port), then initiates a query. Queries are performed recursively from the patient through the studies, series and instance levels until all matching instances have been listed. When Remote AE does not supports patient query level, the Dicompass automatically switch to study query level.

MOVE-SCU

MOVE-SCU is activated through the user interface when a user selects a patient, study, series or instance for retrieval. A connection to the remote AE is established to initiate and monitor the retrieval and the STORAGE-SCP AE receives the retrieved instances.

MOVE-SCU is also automatically activated when user tries to open instances from local database, where no image data is available on local machine.

Print SCU

Print SCU is activated through the user interface when a user select currently displayed instances for printing on DICOM compatible printer. Print SCU performs N-CREATE and N-SET on remote AE and initiates printing.

MWL SCU

Print SCU is activated through the user interface when a user wants to perform digitalization or dicomization operation and worklist study selection is enabled in Dicompass’s configuration. The Dicompass queries remote AE for procedure steps scheduled for specified AET and date.

MPPS SCU

When configured, MPPS SCU is actived immediately after an user select scheduled procedure step from modality worklist and sets step state to STARTED. After image acquire MPPS SCU sets step state to COMPLETED.

Storage Commitment SCU

Storage Commitment SCU accepts Associations to receive N-EVENT-REPORT notifications for the Storage Commitment Push Model SOP Class. Storage Commitment requests are send only when configured. User message dialog can be shown upon processing of incoming N-EVENT-REPORT.

Verification

The Dicompass accepts associations from applications that wish to perform a verification (C-ECHO) operation on the Dicompass.

Associated Real World Activity - Verification

The real-world activity associated with the C-ECHO request is that an external application wishes to verify network or server operation without initiating any actual work.

Acceptable Presentation Contexts - Verification

Following table shows the presentation contexts that may be accepted by Dicompass for verification operations.

Table 9. Acceptable Presentation Contexts for Dicompass for Verification
Presentation Context Table
Abstract Syntax		Transfer Syntax		Role	Extended Negotiation
Name	UID	Name List	UID List
Verification	1.2.840.10008.1.1	DICOM Implicit VR Little Endian	1.2.840.10008.1.2	SCP	None

SOP Specific Conformance for SOP Class - Verification

The Dicompass provides standard conformance for DICOM SOP Verification class.

Presentation Context Acceptance Criterion - Verification

The Dicompass will accept any number of verification SOP classes that are listed in a table above. The Dicompass has no allowed AETs list, so it is responding to any remote AE. In the event that the Dicompass runs out of resources when trying to accept multiple presentation contexts, Dicompass will reject the association request.

The Dicompass does not check for duplicate presentation contexts and will accept duplicate presentation contexts.

Transfer Syntax Selection Policies - Verification

The Dicompass only supports the Implicit VR Little Endian transfer syntax when accepting verification requests. Any proposed presentation context which includes the Implicit VR Little Endian transfer syntax will be accepted with the Implicit VR Little Endian transfer syntax. Any proposed presentation context that does not include the Implicit VR Little Endian transfer syntax will be rejected.

Query / retrieve

Associated Real World Activity - Query / Retrieve

When user performs remote search via user interface by clicking on button Search, the Dicompass will initiate C-FIND request to remote AE specified in format AET@host:port. Any matching patients and/or studies returned by the remote AE will be displayed, otherwise a timeout error or any error response from the remote AE will be displayed.

Proposed Presentation Contexts - Query / Retrieve

Following table shows presentation contexts used by Dicompass when initiating C-FIND requests to remote Query/Retrieve SCP applications.

Proposed Presentation Contexts for Dicompass for Query / Retrieve

Patient Root Query/Retrieve Information Model - FIND

1.2.840.10008.5.1.4.1.2.1.1