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
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 |
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.
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.
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:
Application Context Name |
1.2.840.10008.3.1.1.1 |
Number of associations
Each association is processed in separate thread.
Maximum number of simultaneous associations |
5 |
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.
Maximum number of outstanding asynchronous transactions |
1 |
Implementation Identifying Information
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.
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
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:
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.
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
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
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 |
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 |
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
SOP Specific Conformance
STORAGE-SCP provides standard conformance to the Storage Service Class.
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.
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 |
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
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
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 |
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
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
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
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.
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.
-
Dicompass opens an association with the DICOM printer.
-
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.
-
N-CREATE on the Film Session SOP Class creates a Film Session.
-
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).
-
N-SET on the Image Box SOP Class transfers the contents of the film sheet to the printer.
-
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.
-
N-ACTION on the Film Session SOP Class instructs the printer to print the entire film session.
-
The DICOM printer prints the requested number of film sheets
-
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.
-
N-DELETE on the Film Box SOP Class deletes the film box and its content.
-
N-DELETE on the Film Session SOP Class deletes the complete Film Session SOP Instance hierarchy.
-
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.
-
Dicompass opens an association with the DICOM printer.
-
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.
-
N-CREATE on the Film Session SOP Class creates a Film Session.
-
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).
-
N-SET on the Image Box SOP Class transfers the contents of the film sheet to the DICOM printer.
-
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.
-
N-ACTION on the Film Box SOP Class instructs the printer to print the Film box.
-
The DICOM printer prints the requested number of film sheets
-
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.
-
N-DELETE on the Film Box SOP Class deletes the film box and its content.
-
N-DELETE on the Film Session SOP Class deletes the complete Film Session SOP Instance hierarchy.
-
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.
-
The Dicompass AE opens an association to the Modality Worklist SCP.
-
The Dicompass AE sends a C-FIND request to the Modality Worklist SCP containing the Worklist Query attributes.
-
The Modality Worklist SCP returns a C-FIND response containing the requested attributes of the first matching Worklist Item.
-
The Modality Worklist SCP returns another C-FIND response containing the requested attributes of the second matching Worklist Item.
-
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).
-
The Dicompass AE closes the association with the Modality Worklist SCP.
-
The user selects a Worklist Item from the Worklist and prepares to acquire new images.
-
The Dicompass AE opens an association with the MPPS SCP.
-
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).
-
The Dicompass AE closes the association with the MPPS SCP.
-
All images are acquired and stored in temporary directory (alternatively to local database or PACS) .
-
The Dicompass AE opens an association with the MPPS SCP.
-
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).
-
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.
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
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:
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.
-
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.