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.

images/common/modules.png
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.

images/common/app_data_flow.png
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.

  1. Proposed Presentation Contexts for Dicompass for Query / Retrieve

Presentation Context Table

Abstract Syntax

Transfer Syntax

Role

Extended Negotiation

Name

UID

Name List

UID List

Patient Root Query/Retrieve Information Model - FIND

1.2.840.10008.5.1.4.1.2.1.1

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

Patient Root Query/Retrieve Information Model - MOVE

1.2.840.10008.5.1.4.1.2.1.2

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

Patient Root Query/Retrieve Information Model - GET

1.2.840.10008.5.1.4.1.2.1.3

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCP

None

Study Root Query/Retrieve Information Model - FIND

1.2.840.10008.5.1.4.1.2.2.1

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

Study Root Query/Retrieve Information Model - MOVE

1.2.840.10008.5.1.4.1.2.2.2

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

Study Root Query/Retrieve Information Model - GET

1.2.840.10008.5.1.4.1.2.2.3

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCP

None

SOP Specific Conformance for SOP Class - Query / Retrieve

Table below contains the key matching methods supported by Dicompass when initiating C-FIND requests to remote Query/Retrieve SCP applications:

Table 10. Key Matching Methods Used When Initiating C-FIND Requests
Key Matching Methods Description

S

Single Value Matching

U

Universal Matching

*

Wild-Card Matching

R

Date Range Matching

Table below indicates which keys are used by the Dicompass for the Patient Root information model when initiating C-FIND requests to remote Query/Retrieve SCP applications.

Table 11. Keys Used by Dicompass for Patient Root Information Model
Level Description Tag Matching Method

SOP Common

Specific character set

(0008,0005)

None

Patient

Patient Name

(0010,0010)

S,U,*

Patient ID

(0010,0020)

S,U,*

Patient´s Birth Date

(0010,0030)

S,U,R

Patient´s Sex

(0010,0040)

S

Study

Study Date

(0008,0020)

S,U,R

Study Description

(0008,1030)

S,U,*

Study Instance UID

(0020,000D)

S

Accession Number

(0008,0050)

S

Series

Series Description

(0008,103E)

S,U,*

Modality

(0008,0060)

S

Series Instance UID

(0020,000E)

S

Instance

SOP Class UID

(0008,0016)

S

SOP Instance UID

(0008,0018)

S

All queries are initiated at the highest level of the information model (the PATIENT level), and then for each response received, recursively repeated at the next lower levels (the STUDY, SERIES and then IMAGE levels), in order to completely elucidate the “tree” of instances available on the remote AE (from which the user may subsequently request a retrieval at any level).

The Dicompass will try use PATIENT level first, if not supported by remote AE, Dicompass will fallback to use STUDY level.

The retrieval is performed from the AE that was specified in the Retrieve AE attribute returned from the query performed by FIND-SCU. The instances are retrieved to the current application’s local database by specifying the destination as the AE Title of the STORE-SCP AE of the local application. This implies that the remote C-MOVE SCP must be preconfigured to determine the presentation address corresponding to the STORE-SCP AE. The STORE-SCP AE will accept storage requests addressed to it from anywhere, so no pre-configuration of the local application to accept from the remote AE is necessary (except in so far as it was necessary to configure FIND-SCU).

Store

SOP Classes supported by Storage-SCU & Storage-SCP

Table 12. SOP Classes supported by Storage-SCU & Storage-SCP
SOP Class Name SOP Class UID SCU SCP Transfer syntax

Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7

yes

yes

see table IMAGE TS

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.6.1

yes

yes

see table IMAGE TS

Computed Radiography Image Storage

1.2.840.10008.5.1.4.1.1.1

yes

yes

see table IMAGE TS

Digital X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.1

yes

yes

see table IMAGE TS

Digital Mammography X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.2

yes

yes

see table IMAGE TS

MR Image Storage

1.2.840.10008.5.1.4.1.1.4

yes

yes

see table IMAGE TS

X-Ray Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.12.1

yes

yes

see table IMAGE TS

X-Ray Radiofluoroscopic Image Storage

1.2.840.10008.5.1.4.1.1.12.2

yes

yes

see table IMAGE TS

Nuclear Medicine Image Storage

1.2.840.10008.5.1.4.1.1.20

yes

yes

see table IMAGE TS

VL Endoscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.1

yes

yes

see table IMAGE TS

VL Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.2

yes

yes

see table IMAGE TS

VL Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4

yes

yes

see table IMAGE TS

VL Slide-Coordinates Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.3

yes

yes

see table IMAGE TS

Positron Emission Tomography Image Storage

1.2.840.10008.5.1.4.1.1.128

yes

yes

see table IMAGE TS

Enhanced CT Image Storage

1.2.840.10008.5.1.4.1.1.2.1

yes

yes

see table IMAGE TS

Enhanced MR Image Storage

1.2.840.10008.5.1.4.1.1.4.1

yes

yes

see table IMAGE TS

Enhanced PET Image Storage

1.2.840.10008.5.1.4.1.1.130

yes

yes

see table IMAGE TS

MR Spectroscopy Storage

1.2.840.10008.5.1.4.1.1.4.2

yes

yes

see table IMAGE TS

CT Image Storage

1.2.840.10008.5.1.4.1.1.2

yes

yes

see table IMAGE TS

Video Endoscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.1.1

yes

yes

see table VIDEO TS

Video Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.2.1

yes

yes

see table VIDEO TS

Video Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4.1

yes

yes

see table VIDEO TS

RT Image Storage

1.2.840.10008.5.1.4.1.1.481.1

yes

yes

see table DATA TS

RT Plan Storage

1.2.840.10008.5.1.4.1.1.481.5

yes

yes

see table DATA TS

RT Dose Storage

1.2.840.10008.5.1.4.1.1.481.2

yes

yes

see table DATA TS

RT Structure Set Storage

1.2.840.10008.5.1.4.1.1.481.3

yes

yes

see table DATA TS

Siemens CSA Non-Image Storage

1.3.12.2.1107.5.9.1

yes

yes

see table DATA TS

RT Beams Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.4

yes

yes

see table DATA TS

RT Brachy Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.6

yes

yes

see table DATA TS

RT Treatment Summary Record Storage

1.2.840.10008.5.1.4.1.1.481.7

yes

yes

see table DATA TS

Basic Text SR Storage

1.2.840.10008.5.1.4.1.1.88.11

yes

yes

see table DATA TS

Enhanced SR Storage

1.2.840.10008.5.1.4.1.1.88.22

yes

yes

see table DATA TS

Comprehensive SR Storage

1.2.840.10008.5.1.4.1.1.88.33

yes

yes

see table DATA TS

Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

yes

yes

see table DATA TS

Storage Transfer syntaxes

Table 13. IMAGE TS
Transfer syntax UID

JPEG-LS Lossless Image Compression

1.2.840.10008.1.2.4.80

JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])

1.2.840.10008.1.2.4.70

JPEG Lossless, Non-Hierarchical (Process 14)

1.2.840.10008.1.2.4.57

JPEG 2000 Image Compression (Lossless Only)

1.2.840.10008.1.2.4.90

Explicit VR Little Endian

1.2.840.10008.1.2.1

Implicit VR Little Endian

1.2.840.10008.1.2

JPEG Baseline (Process 1)

1.2.840.10008.1.2.4.50

JPEG Extended (Process 2 & 4)

1.2.840.10008.1.2.4.51

JPEG-LS Lossy (Near-Lossless) Image Compression

1.2.840.10008.1.2.4.81

JPEG 2000 Image Compression

1.2.840.10008.1.2.4.91

RLE Lossless

1.2.840.10008.1.2.5

Table 14. VIDEO TS
Transfer syntax UID

MPEG2 Main Profile @ Main Level

1.2.840.10008.1.2.4.100

MPEG-4 AVC/H.264 High Profile / Level 4.1

1.2.840.10008.1.2.4.102

Table 15. DATA TS
Transfer syntax UID

No Pixel Data

1.2.840.10008.1.2.4.96

Explicit VR Little Endian

1.2.840.10008.1.2.1

Implicit VR Little Endian

1.2.840.10008.1.2

Activity – Send Storage Request

Description and Sequencing of Activities

For each instance selected from the user interface to be transferred, a single attempt will be made to transmit it to the selected remote AE. If the send fails, for whatever reason, no retry will be performed, and an attempt will be made to send the next instance.

When configured Dicompass sends Storage Commitment request via N-ACTION to Storage Commitment SCP which is considered to be same as STORAGE-SCP. When incoming N-EVENT-REPORT is processed, information about storage result can be displayed. Dicompass provides two options for result notification:

  • show only information about storage failures

  • show information about storage success and failures

Proposed Presentation Contexts

STORAGE-SCU will propose Presentation Contexts only for the SOP Class of the instance that is to be transferred. For that SOP Class, STORAGE-SCU will propose one Presentation Contexts for each SOP Class in storage request with Transfer Syntax in which is a SOP instance stored.

Extended Negotiation

No extended negotiation is performed.

SOP Specific Conformance

STORAGE-SCU provides standard conformance to the Storage Service Class.

Activity - Receive Storage Request

Description and Sequencing of Activities

As instances are received they are copied to the local file system and a record inserted into the local database. If the received instance is a duplicate of a previously received instance, the old file and database record will be overwritten with the new one.

Accepted Presentation Contexts

Acceptable Presentation Contexts for STORAGE-SCP and Receive Storage Request can be found in table above.

Extended Negotiation

No extended negotiation is performed, though STORAGE-SCP:

  • is a Level 2 Storage SCP (Full – does not discard any data elements)

  • does not support digital signatures

  • does not coerce any received data elements

Transfer Syntax Selection Policies

If offered a choice of Transfer Syntaxes in a Presentation Context, Dicompass will select first matching Transfer Syntax in order in tables IMAGE TS, VIDEO TS and DATA TS according to SOP Class.

SOP Specific Conformance

STORAGE-SCP provides standard conformance to the Storage Service Class.

Print

Printing activity is described in article Activity - Printing.

Proposed Presentation Contexts - Printing

Following table shows presentation contexts used by Dicompass when initiating print requests to remote PRINT SCP applications.

Table 16. Proposed Presentation Contexts for Dicompass for Printing

Presentation Context Table

Abstract Syntax

Transfer Syntax

Role

Extended Negotiation

Name

UID

Name List

UID List

Basic Color Print Management Meta SOP Class

1.2.840.10008.5.1.1.18

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

Basic Grayscale Print Management Meta SOP Class

1.2.840.10008.5.1.1.9

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

Table 17. SOP Classes for Basic Grayscale Print Management Meta SOP Class and Basic Color Print Management Meta SOP Class
SOP Class Name SOP Class UID

Basic Film Session

1.2.840.10008.5.1.1.1

Basic Film Box

1.2.840.10008.5.1.1.2

Basic Grayscale Image Box

1.2.840.10008.5.1.1.4

Basic Color Image Box

1.2.840.10008.5.1.1.4.1

Basic Annotation Box SOP Class

1.2.840.10008.5.1.1.15

SOP Specific Conformance for the Film Box SOP Class

Table 18. Film Box SOP Class N-CREATE Request Attributes
Attribute Name Tag VR Value Presence of Value Source

Image Display Format

(2010,0010)

CS

STANDARD_rows_,cols

ALWAYS

User

Film Orientation

(2010,0040)

CS

PORTRAIT or LANDSCAPE

ANAP

User

Film Size ID

(2010,0050)

CS

8INX10IN, 8_5INX11IN, 10INX12IN, 10INX14IN, 11INX14IN, 11INX17IN, 14INX14IN, 14INX17IN, 24CMX24CM, 24CMX30CM, A4, A3

ANAP

User

Annotation Display Format ID

(2010,0030)

CS

User input - see printer’s Conformance Statement

ANAP

User

Referenced Film Session Sequence

(2010,0500)

SQ

ALWAYS

Auto

>Referenced SOP Class UID

(0008,1150)

UI

1.2.840.10008.5.1.1.1

ALWAYS

Auto

>Referenced SOP Instance UID

(0008,1155)

UI

From created Film Session SOP Instance

ALWAYS

Auto

SOP Specific Conformance for the Image Box SOP Class

Table 19. Image Box SOP Class N-SET Request Attributes - Grayscale printing
Attribute Name Tag VR Value Presence of Value Source

Image Position

(2020,0010)

US

1

ALWAYS

Auto

Basic Grayscale Image Sequence

(2020,0110)

SQ

ALWAYS

Auto

>Samples Per Pixel

(0028,0002)

US

1

ALWAYS

Auto

>Photometric Interpretation

(0028,0004)

CS

MONOCHROME2

ALWAYS

Auto

>Rows

(0028,0010)

US

value derrived from image to print

ALWAYS

Auto

>Columns

(0028,0011)

US

value derrived from image to print

ALWAYS

Auto

>Pixel Aspect Ratio

(0028,0034)

IS

value derrived from image to print

ALWAYS

Auto

>Bits Allocated

(0028,0100)

US

value derrived from image to print

ALWAYS

Auto

>Bits Stored

(0028,0101)

US

value derrived from image to print

ALWAYS

Auto

>High Bit

(0028,0102)

US

value derrived from image to print

ALWAYS

Auto

>Pixel Representation

(0028,0103)

US

value derrived from image to print

ALWAYS

Auto

>Pixel Data

(7FE0,0010)

OB

Pixels of image to print

ALWAYS

Auto

Table 20. Image Box SOP Class N-SET Request Attributes - Color printing
Attribute Name Tag VR Value Presence of Value Source

Image Position

(2020,0010)

US

1

ALWAYS

Auto

Basic Color Image Sequence

(2020,0111)

SQ

ALWAYS

Auto

>Samples Per Pixel

(0028,0002)

US

3

ALWAYS

Auto

>Photometric Interpretation

(0028,0004)

CS

RGB

ALWAYS

Auto

>Rows

(0028,0010)

US

value derrived from image to print

ALWAYS

Auto

>Columns

(0028,0011)

US

value derrived from image to print

ALWAYS

Auto

>Pixel Aspect Ratio

(0028,0034)

IS

value derrived from image to print

ALWAYS

Auto

>Bits Allocated

(0028,0100)

US

8

ALWAYS

Auto

>Bits Stored

(0028,0101)

US

8

ALWAYS

Auto

>High Bit

(0028,0102)

US

7

ALWAYS

Auto

>Pixel Representation

(0028,0103)

US

0

ALWAYS

Auto

>Planar Configuration

(0028,0006)

US

0

ALWAYS

Auto

>Pixel Data

(7FE0,0010)

OB

Pixels of image to print

ALWAYS

Auto

Modality Worklist

Description and Sequencing of Activities

The request for a Modality Worklist Query is initiated by user interaction, i.e. when user requests to aquire digital data by digitalization of video signal or dicomization of digital images or video files. Worklist query is can be also performed by Modality Worklist Console that is separated Dicompass module.

The Dicompass request all items with status SCHEDULED. Query can also contain filter for Scheduled Station AE (local Dicompass AET by default) and Scheduled Procedure Step Start Date (actual date by default). User interaction with user interface specifies which matching keys are included into query.

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

Sequence diagram for Modality Worklist Query can be found in chapter Activity - Acquire Images.

Proposed Presentation Contexts

Table 21. Proposed Presentation Contexts for Dicompass for Modality Worklist Query

Presentation Context Table

Abstract Syntax

Transfer Syntax

Role

Extended Negotiation

Name

UID

Name List

UID List

Modality Worklist Information Model – FIND

1.2.840.10008.5.1.4.31

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

SOP Specific Conformance for Modality Worklist

Table 22. Worklist request identifier
Attribute Name Tag VR R Q D IOD

SOP Common

Specific Character Set

(0008,0005)

CS

yes

Scheduled Procedure Step

Scheduled Station AET

(0040,0001)

AE

yes

yes

Scheduled Procedure Step Start Date

(0040,0002)

DA

yes

yes

Scheduled Procedure Step Start Time

(0040,0003)

DA

yes

Modality

(0008,0060)

CS

yes

yes

Scheduled Procedure Step Description

(0040,0007)

CS

yes

yes

Scheduled Station Name

(0040,0010)

SH

yes

Scheduled Procedure Step Location

(0040,0011)

SH

yes

Scheduled Protocol Code Sequence

(0040,0010)

SQ

yes

Scheduled Procedure Step ID

(0040,0009)

SH

yes

yes

Requested Procedure

Requested Procedure ID

(0040,1001)

SH

yes

yes

Requested Procedure Description

(0032,1060)

SH

yes

yes

yes

Study Instance UID

(0020,000D)

UI

yes

yes

Requested Procedure Code Sequence

(0032,1064)

SQ

yes

yes

Imaging Service Request

Accession Number

(0008,0050)

SH

yes

yes

Visit Identification

Admission ID

(0038,0010)

LO

yes

Patient Identification

Patient Name

(0010,0010)

PN

yes

yes

yes

Patient ID

(0010,0020)

LO

yes

yes

yes

Issuer of Patient ID

(0010,0021)

LO

yes

yes

Patient Demographic

Patient’s Birth Date

(0010,0030)

DA

yes

yes

yes

Patient’s Sex

(0010,0040)

DA

yes

yes

yes

Attribute Name

Attributes supported to build an Dicompass Worklist Request Identifier

Tag

DICOM tag for this attribute

VR

DICOM VR for this attribute

R

Return keys. An tick will indicate that Dicompass will supply this attribute as Return Key with zero length for Universal Matching. The Dicompass will support retired date format (yyyy.mm.dd) for "Patient’s Birth Date" and "Scheduled Procedure Step Start Date" in the response identifiers. For "Scheduled Procedure Step Start Time" also retired time format as well as unspecified time components are supported.

Q

Query Key. An tick will indicate that Dicompass will supply this attribute as matching key, if entered in the Query Patient Worklist dialog. For example, the Scheduled Station AET can be entered thereby restricting Worklist responses to Procedure Steps scheduled for the AET.

D

Displayed keys. An tick indicates that this worklist attribute is displayed to the user during a patient registration dialog. For example, Patient Name will be displayed when registering the patient prior to an examination.

IOD

An tick indicates that this Worklist attribute is included into all Object Instances created during performance of the related Procedure Step.

Modality Performed Procedure Step

Description and Sequencing of Activities

Association to the configured Modality Performed Procedure Step SCP is established immediately after Patient selection from Worklist and related MPPS SOP Instance will be created. Status of created MPPS SOP Instance is "IN PROGRESS".

The Dicompass does not support creation of "unscheduled cases". MPPS can not be used for patient registered manually.

When image acquisition is completed, state of MPPS SOP instance is set to COMPLETED.

Sequence diagram for Modality MPPS creation and update can be found in chapter Activity - Acquire Images.

Proposed Presentation Contexts

Table 23. Proposed Presentation Contexts for Dicompass for Modality Worklist Query

Presentation Context Table

Abstract Syntax

Transfer Syntax

Role

Extended Negotiation

Name

UID

Name List

UID List

Modality Performed Procedure Step

1.2.840.10008.3.1.2.3.3

Implicit VR Little Endian Explicit VR Little Endian Explicit VR Big Endian
1.2.840.10008.1.2 1.2.840.10008.1.2.1 1.2.840.10008.1.2.2

SCU

None

SOP Specific Conformance for Modality Performed Procedure Step

Following table provides a description of the MPPS N-CREATE and N-SET request identifiers sent by Dicompass. Empty cells in the N-CREATE and N-SET columns indicate that the attribute is not sent. An tick indicates that an appropriate value will be sent. A “Zero length” attribute will be sent with zero length.

Table 24. MPPS N-CREATE / N-SET request identifier
Attribute Name Tag VR N-CREATE N-SET

Specific Character Set

(0008,0005)

CS

From configuration

Modality

(0008,0060)

CS

From Modality Worklist

Referenced Patient Sequence

(0008,1120)

SQ

Zero length

Patient’s Name

(0010,0010)

PN

From Modality Worklist

Patient ID

(0010,0020)

LO

From Modality Worklist

Issuer of Patient ID

(0010,0021)

LO

From Modality Worklist

Patient’s Birth Date

(0010,0030)

DA

From Modality Worklist

Patient’s Sex

(0010,0040)

CS

From Modality Worklist

Performed Station AE Title

(0040,0241)

AE

From configuration

Performed Procedure Step Start Date

(0040,0244)

DA

Actual start date

Performed Procedure Step Start Time

(0040,0245)

TM

Actual start time

Performed Procedure Step End Date

(0040,0250)

DA

Zero length

Actual end time

Performed Procedure Step End Time

(0040,0251)

TM

Zero length

Actual end time

Performed Procedure Step Status

(0040,0252)

CS

IN PROGRESS

IN PROGRESS or COMPLETED

Performed Procedure Step ID

(0040,0253)

SH

Same as Scheduled Procedure Step ID

Performed Procedure Type Description

(0040,0255)

LO

Zero length

Performed Protocol Code Sequence

(0040,0260)

SQ

Zero length

Scheduled Step Attributes Sequence

(0040,0270)

SQ

One item

> Accession Number

(0008,0050)

SH

From Modality Worklist

> Study Instance UID

(0020,000D)

UI

From Modality Worklist

> Scheduled Procedure Step Description

(0040,0007)

SH

From Modality Worklist

> Scheduled Procedure Step ID

(0040,0009)

SH

From Modality Worklist

Performed Procedure Step Discontinuation Reason Code Sequence

(0040,0281)

SQ

Zero length

Performed Series Sequence

(0040,0340)

SQ

One or more items

> Retrieve AE Title

(0008,0054)

AE

AET where are instances stored

> Series Description

(0008,103E)

LO

User input

> Referenced Image Sequence

(0008,1140)

SQ

One or more items

>> Referenced SOP Class UID

(0008,1150)

UI

yes

>> Referenced SOP Instance UID

(0008,1155)

UI

yes

> Series Instance UID

(0020,000E)

UI

yes

Activities

Printing

The Dicompass allows to configure if printer support printing whole session at once or if printing by film box is required.

Printing whole print session at once

When the DICOM printer supports printing whole session at once, printing process is visualised on following sequence diagram.

images/common/printing_session.png
Figure 3. Printing session
  1. Dicompass opens an association with the DICOM printer.

  2. N-GET on the DICOM printer is used to obtain current printer status information. If the DICOM printer reports a status of FAILURE, the print-job is switched to a failed state and the user informed.

  3. N-CREATE on the Film Session SOP Class creates a Film Session.

  4. N-CREATE on the Film Box SOP Class creates a Film Box linked to the Film Session. A single Image Box will be created as the result of this operation (format and layout of the filmbox is selected according to configuration in print dialog).

  5. N-SET on the Image Box SOP Class transfers the contents of the film sheet to the printer.

  6. N-SET on the Annotation Box SOP class set captions on page if this feature is supported by the DICOM printer and if its configured in the Dicompass’s DICOM printer management dialog.

  7. N-ACTION on the Film Session SOP Class instructs the printer to print the entire film session.

  8. The DICOM printer prints the requested number of film sheets

  9. The Printer asynchronously reports its status via N-EVENT-REPORT notification (Printer SOP Class). The printer can send this message at any time. Dicompass AE does not require the N-EVENT-REPORT to be sent. Dicompass AE ignores any status retrieved in N-EVENT-REPORT messages.

  10. N-DELETE on the Film Box SOP Class deletes the film box and its content.

  11. N-DELETE on the Film Session SOP Class deletes the complete Film Session SOP Instance hierarchy.

  12. Dicompass AE closes the association with the Printer.

Step 4-6 are repeated for every page of the print job.

Printing each page separately

When the DICOM printer does not support printing whole session at once, printing page by page can be used. Printing process is visualised on following sequence diagram.

images/common/printing_filmbox.png
Figure 4. Printing filmbox
  1. Dicompass opens an association with the DICOM printer.

  2. N-GET on the DICOM printer is used to obtain current printer status information. If the DICOM printer reports a status of FAILURE, the print-job is switched to a failed state and the user informed.

  3. N-CREATE on the Film Session SOP Class creates a Film Session.

  4. N-CREATE on the Film Box SOP Class creates a Film Box linked to the Film Session. A single Image Box will be created as the result of this operation (format and layout of the filmbox is selected according to configuration in print dialog).

  5. N-SET on the Image Box SOP Class transfers the contents of the film sheet to the DICOM printer.

  6. N-SET on the Annotation Box SOP class set captions on page if this feature is supported by the DICOM printer and if its configured in the Dicompass’s DICOM printer management dialog.

  7. N-ACTION on the Film Box SOP Class instructs the printer to print the Film box.

  8. The DICOM printer prints the requested number of film sheets

  9. The Printer asynchronously reports its status via N-EVENT-REPORT notification (Printer SOP Class). The printer can send this message at any time. Dicompass AE does not require the N-EVENT-REPORT to be sent. Dicompass AE ignores any status retrieved in N-EVENT-REPORT messages.

  10. N-DELETE on the Film Box SOP Class deletes the film box and its content.

  11. N-DELETE on the Film Session SOP Class deletes the complete Film Session SOP Instance hierarchy.

  12. Dicompass AE closes the association with the Printer.

Step 4-10 are repeated for every page of the print job.

Acquire Images

Following sequence diagram shows action of acquiring new images using patient selection from Modality Worklist and status notification via Modality Performed Procedure Step. When patient is registered manually, none of these steps are performed.

images/common/acquire_images.png
Figure 5. Activity - acquire images
  1. The Dicompass AE opens an association to the Modality Worklist SCP.

  2. The Dicompass AE sends a C-FIND request to the Modality Worklist SCP containing the Worklist Query attributes.

  3. The Modality Worklist SCP returns a C-FIND response containing the requested attributes of the first matching Worklist Item.

  4. The Modality Worklist SCP returns another C-FIND response containing the requested attributes of the second matching Worklist Item.

  5. The Modality Worklist SCP 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 (when there is more matching items, step 4 is repeated).

  6. The Dicompass AE closes the association with the Modality Worklist SCP.

  7. The user selects a Worklist Item from the Worklist and prepares to acquire new images.

  8. The Dicompass AE opens an association with the MPPS SCP.

  9. The Dicompass AE sends an N-CREATE request to the MPPS SCP to create an MPPS instance with status of "IN PROGRESS" and create all necessary attributes. The MPPS SCP acknowledges the MPPS creation with an N-CREATE response (status success).

  10. The Dicompass AE closes the association with the MPPS SCP.

  11. All images are acquired and stored in temporary directory (alternatively to local database or PACS) .

  12. The Dicompass AE opens an association with the MPPS SCP.

  13. The Dicompass AE sends an N-SET request to the MPPS SCP to update the MPPS instance with status of "COMPLETED" and set all necessary attributes. The MPPS SCP acknowledges the MPPS update with an N-SET response (status success).

  14. The Dicompass AE closes the association with the MPPS SCP.

Physical network interfaces

Supported communication stacks

DICOM Upper Layer as defined in Part 8 of the Standard over TCP/IP is supported.

TCP/IP stack

The inherits its TCP/IP stack from installed Java Runtime Environment.

Physical network interface

The is indifferent to the physical medium over which TCP/IP executes; it inherits this from the Java Runtime Environment.

IPv4 and IPv6 support

The Dicompass’s support IPv4 and IPv6 is inheritted from host’s Java Runtime Environment. It does not utilize any of the optional configuration identification or security features of IPv6.

Configuration

AE Title/Presentation address mapping

Local AE Titles

The local AE Title and TCP port are configurable in application settings.

Table 25. Default AE Title configuration
Application Entity Default AE Title Default TCP port

Dicompass

machine host name

11112

Remote AE Titles

Remote AE Titles, TCP/IP addresses and ports can be configured as favorite destination or can be directly entered in search console.

AE title, TCP/IP Address and port for MWL and MPPS support can be configured in program settings.

All AET records in application has format: AET[@host[:port]]

For instance CT01@10.20.0.1:10104 is device with AE Title CT01 listening on IP address 10.20.0.1 on port number 10104.

AE Title is unique identifier of DICOM service (or whole device). AET is text string with maximal length of 16 characters. Allowed characters are: letters A-Z, numbers 0-9, underscore, hyphen, dot and space.

When no port number is specified, default value 104 is used. When even host part (IP address or hostname) is missing, localhost is used. I.e. when you enter address: TEST-PACS, the Dicompass will try to connect to TEST-PACS@127.0.0.1:104.

Parameters

Table 26. Configuration Parameters table
Parameter Configurable Default Value

General Parameters

PDU Size

no

16kB

Time-out waiting for acceptance or rejection Response to an Association Open Request. (Application Level timeout)

no

None

General DIMSE level time-out values

no

10000 ms

Time-out waiting for response to TCP/IP connect() request. (Low-level timeout)

yes

5000 ms

Time-out waiting for acceptance of a TCP/IP message over the network. (Low-level timeout)

yes

15000 ms

Time-out for waiting for data between TCP/IP packets. (Low-level timeout)

yes

5000 ms

Any changes to default TCP/IP settings, such as configurable stack parameters.

no

None

AE Specific Parameters (all AE’s)

Size constraint in maximum object size

no

2 GB

Maximum PDU size the AE can receive

yes

16 kB

Maximum PDU size the AE can send

yes

16 kB

AE specific DIMSE level time-out values

no

None

Number of simultaneous Associations by Service and/or SOP Class

no

50

SOP Class support

no

All supported SOP Classes always proposed and accepted

Transfer Syntax support

no

All supported Transfer Syntaxes always proposed and accepted

Support of character sets

Charset overview

Support extends to correctly decoding and displaying the correct symbol for all names and strings found in the DICOMDIR, in storage instances from media and received over the network, and in the local database.

No specific support for sorting of strings other than in the default character set is provided in the browsers.

Supported character sets

The Dicompass supports following character sets:

Table 27. List of supported character sets

US ASCII

ISO IR 6

ISO 8859-1

ISO IR 100

ISO 8859-2

ISO IR 101

UTF-8

ISO IR 192

When character set specification is missing in source DICOM instance, Dicompass will use default character set defined in configuration instead.

Security

Security Profiles

None supported.

Association level security

None supported.

Any Calling AE Titles and/or IP addresses may open an Association.

Application level security

Client-server mode

User authentification is required when running in client-server mode. Authentification policy can be configured on server. Server specifies multiple roles with list of permissions assigned to these roles. Each user can be assigned to multiple roles which only one can be active at the time.

List of permissions
  • Saving organization configuration

  • Saving machine configuration

  • Saving user configuration

  • DICOM store

  • CD/DVD burning

  • Printing

  • Export JPEG / MPEG

  • Exporting DICOM

Standalone mode

It is possible to limit filesystem write / update permission on config files user.xml, machine.xml and organization.xml. Dicompass respects these file attributes and disallow user to modify configuration in level which can not be saved to XML configuration file. There is no other application security mechanisms in standalone version.