Dcm4chee Arc Cs
Dcm4chee Arc Cs
dcm4che Archive 5
Release 5.10.1
Gunter Zeilinger
2 Table of Content 9
3 Introduction 11
3.1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Networking 15
4.1 Implementation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 AE Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7 Security 109
7.1 Security Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2 Association Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.3 Application Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
i
ii
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Contents 1
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
2 Contents
CHAPTER 1
dcm4che DICOM Archive 5 is a networked computer system used for archiving DICOM objects. It allows external
systems to send DICOM objects to it for permanent storage, retrieve information about such objects, and retrieve the
DICOM objects themselves.
3
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
5
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
7
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Table of Content
9
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration
4.4.1. AE Title/Presentation Address Mapping
4.4.2. Parameters
5. Media Interchange
6. Support of Character Sets
7. Security
7.1 Security Profiles
7.1.1. Secure Transport Connection Profiles
7.1.2. Network Address Management Profiles
7.1.3. Time Synchronization Profiles
7.1.4. Application Configuration Management Profiles
7.1.5. Audit Trail Profiles
7.2 Association Level Security
7.3 Application Level Security
Introduction
Revision History
Audience
This document is written for the people that need to understand how dcm4che DICOM Archive 5 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 products 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 dcm4che DICOM Archive 5
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:
11
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
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.
dcm4che DICOM Archive 5 has participated in an industry-wide testing program sponsored by Integrating the
Healthcare Enterprise (IHE). The IHE Integration Statement for dcm4che DICOM Archive 5, together with the
IHE Technical Framework, may facilitate the process of validation testing.
Informal definitions are provided for the following terms used in this Conformance Statement. The DICOM Standard
is the authoritative source for formal definitions of these terms.
Abstract Syntax The information agreed to be exchanged between applications, generally equivalent to a Ser-
vice/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 (AET) 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 Se-
quence (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 Appli-
cation 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.
12 Chapter 3. Introduction
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
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 Class (SOP Class) The specification of the network or media transfer (service) of a particular
type of data (object); the fundamental unit of DICOM interoperability specification. Examples: Ultrasound
Image Storage Service, Basic Grayscale Print Management.
Service/Object Pair Instance (SOP Instance) An information object; a specific occurrence of information ex-
changed in a SOP Class. Examples: a specific x-ray image.
Tag A 32-bit identifier for a data element, represented as a pair of four digit hexadecimal numbers, the group
and the element. If the group number is odd, the tag is for a private (manufacturer-specific) data element.
Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element]
Transfer Syntax The encoding used for exchange of DICOM information objects and messages. Examples: JPEG
compressed (images), little endian explicit value representation.
Unique Identifier (UID) A globally unique dotted decimal string that identifies a specific object or a class of
objects; an ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOP Instance UID.
Value Representation (VR) The format type of an individual DICOM data element, such as text, an integer, a
persons 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.
14 Chapter 3. Introduction
CHAPTER 4
Networking
Implementation Model
The core component of dcm4che DICOM Archive 5 is a Java Enterprise Application deployed in WildFly AS, which
provides DICOM services over the DICOM Upper Layer protocol (DUL) and HTTP, HL7 v2 services over the Minimal
Lower Layer Protocol (MLLP), various proprietary RESTful services and a Web UI accessable by HTML 5 compliant
web browsers.
It uses any LDAP v3 compatible LDAP server as configuration backend and a relational database for supporting query
and data management services.
The received DICOM objects are not stored in the database, but in a separated storage backend - typically any type of
file system, but also cloud storage supported by Apache jclouds may be used as storage backend.
System-log and audit messages may be stored into the Elastic Stack.
RESTful services and the Web UI may be secured with OpenID Connect using Keycloak as Authentication Server.
System components may be distributed over multiple hosts, as multiple instances of the Archive Application may
share one LDAP server and one database.
System components of dcm4che DICOM Archive 5 are also available as Docker images to run within Docker contain-
erns.
Conceptually the network services may be modeled as the following separate AEs, though they may share one AE
Title, or one AE may have multiple instances identified by different AE Titles, with different configuration.
15
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Storage Application Entity, which receives incoming images and other Composite Object Instances and accepts
requests for commitment for the safekeeping of the received objects.
Query/Retrieve Application Entity, which processes queries for Patient, Study, Series, and Instance information
and also processes retrieval requests, sending the requested objects to the retrieve destination AE.
Workflow Application Entity, which processes queries for Scheduled Procedure Steps, receives Performed Pro-
cedure Step messages and optionally forwards them to any remote AE, and also notifies remote AEs about the
availability of received instances.
STOW-RS, which receives images and other Composite Object Instances via HTTP POST requests.
QIDO-RS, which provides access to Patient, Study, Series, and Instance data of received objects via HTTP GET
requests.
WADO-URI, which provides access to individual DICOM Objects - as DICOM file or rendered to non-DICOM
media types for display - via HTTP GET requests.
WADO-RS, which provides access to the metadata, the bulk data or the whole DICOM Objects, of a Study or
Series via HTTP GET requests.
The Storage Application Entity receives images and other Composite Object Instances from remote AEs.
Compressed images and non-image objects are stored as received on the storage backend configured for the Storage
AE. Uncompressed images may be compressed according configurable compression rules before they are stored with
all attributes on the storage backend.
A configurable sub-set of attributes are extracted from the received objects and stored in the data base. These attributes
may be coerced according configurable coercion rules on receive time or by data management functions at any time
after.
If configured, the Storage AE queries an external RESTful service for permission to store a study on receive of the first
object of a study. If the service does not grant the permission to store the study, the object and all following received
objects of that study will be refused.
The behavior on receive of an object which SOP Instance UID matches with the SOP Instance UID of a previous
received object is configurable: The new received object may overwrite the previous one, be stored additionally or
just be ignored, dependent if it was sent by the same source and/or dependent if it belongs to the same series as the
previous received object. That allows to operate with object sources which does not support use of Imaging Object
Change Management (IOCM) services to correct failures in the originally sent objects, but which just send the objects
with corrected attributes but unchanged SOP Instance UID again.
16 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The behavior how to treat differences in Patient, Study or Series attributes in received instances belonging to the same
Patient, Study or Series is also configurable: the attributes of the already existing Patient, Study or Series record in the
data base may
not be updated at all,
be supplemented with attributes from the new received object, not included in the existing record,
be additionally overwritten by different values of the attributes in the new received object,
be completely replaced by the extracted attributes from the new received object.
The Storage AE may also associate a configured Access Control ID to a received study. Query/Retrieve AEs can be
configured to only provide access to data and objects of studies, which associated Access Control ID matches one of
the Access Control IDs configured for that Query/Retrieve AE.
If configured, the Storage AE will set the Retention Period of received studies according a configured Study Retention
Policy. Individual series of a study may get a different Rentention Period than the whole study. If activated, studies
- or individual series - will be deleted automatically after its Rentention Period expires. On the other hand, dcm4che
DICOM Archive 5 can be configured to prevent manual deletion of objects of studies which Rentention Period is not
yet expired.
The Storage AE can also be configured to act as a cache archive, which deletes least recent accessed studies according
configured thresholds of the storage backend.
Received objects may be exported according configurable export rules, which are triggered by matching send-
ing/receiving AE Titles and/or matching object attribute values. Received objects of one series or study may be
accumulated, before all objects of the series or study are exported in one task. Export by DICOM storage is invoked
by the Query/Retrieve Application Entity.
Objects may be also received from the Storage AE as result of a forwarded retrieve request to a configured fallback
archive by the Query/Retrieve Application Entity. In that case, the received objects will be forwarded immediately to
the final retrieve destination by the Query/Retrieve Application Entity.
The receive of objects may trigger the notification of configured remote AEs by the DICOM Instance Available Noti-
fication service invoked by the Workflow Application Entity.
If the Storage AE receives a Key Object Selection (KOS) Document with a Document Title which matches one of
the configured Rejection Note Code Values, the object will be treated as Rejection Note and the instances referenced
by the object will be marked as rejected. The Key Selection Object Document itself is stored on the storage backend
as other objects received from the Storage AE. Further treatment of the rejected instances and the KOS Document is
specific to the particular type of rejection.
By default, the KOS Document Titles specified by Imaging Object Change Management (IOCM) are configured:
(113001, DCM, Rejected for Quality Reasons)
Hide/Show rejected instances dependend on Query/Retrieve AE
Show KOS Document
Ignore subsequent occurrence of rejected instances
(113037, DCM, Rejected for Patient Safety Reasons)
Hide rejected instances
Show KOS Document
Reject subsequent occurrence of rejected instances
The Query/Retrieve Application Entity processes queries for Patient, Study, Series, and Instance information of re-
ceived DICOM objects invoked by remote AEs. Attributes of requested entities are fetched from the database. The
objects on the storage backend are not accessed. Therefore, only the configurable sub-set of attributes which were
extracted from the received objects and stored in the data base is provided.
In addition, the Query/Retrieve Application Entity provides the ability to retrieve/transfer received DICOM objects to
remote AEs. The transfer may be originated by a retrieve request from the same or from another remote AE, it may be
caused by a configured Export Rule for received objects, or it may be triggered by the Archive Web UI, which itself
uses a RESTful service to schedule the transfer, which may be also used by other web clients.
The Query/Retrieve Application Entity may forward retrieve requests for which no matching objects were found in
the data base to a configured other DICOM Archive. Two configuration options are available:
1. Preserve the original Move Destination AE Title in the forwarded retrieve request, so the other DICOM Archive
will directly send the requested objects to the destination AE.
2. Replace the original Move Destination AE Title in the forwarded retrieve request with the AE Title of the/a
Storage Application Entity, so the other DICOM Archive will send the requested objects to the Storage AE
and the Query/Retrieve AE will forward the received objects to the original Move Destination AE. If the other
DICOM Archive signals that not all requested objects could be transfered to the Storage AE successfully, the
Study and Series of the received objects are marked as incomplete in the data base and following retrieve request
for that Study or Series will trigger to retry to retrieve the Study or Series from the other DICOM Archive.
Worklist Update attempts to download a Worklist from a remote node. If the Workflow AE establishes an Association
to a remote AE, it will transfer all worklist items via the open Association. During receiving the worklist response
items are counted and the query processing is canceled if the configurable limit of items is reached. The results will
be displayed in a separate list, which will be cleared with the next Worklist Update. The Workflow AE performs the
creation of a MPPS Instance automatically whenever images are acquired. Further updates on the MPPS data can be
18 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
performed interactively from the related MPPS user interface. The MPPS Complete or Discontinued states can
only be set from the user interface.
STOW-RS
The reception of a STOW-RS POST request will activate the STOW-RS Service. The storage request is based upon
the accept headers in the STOW-RS POST request. The response includes an HTTP status line, including a status-
code and its associated textual phrase, followed by an XML message indicating success, warning, or failure for each
instance stored by the STOW-RS service.
QIDO-RS
The reception of a QIDO-RS GET request will activate the QIDO-RS Provider. An internal query request is sent to
the search capabilities of the associated PACS or Vendor Neutral Archive (VNA). The search result is based upon the
URL of the QIDO-RS GET request. The response is a status code indicating the success, warning, or failure of the
search along with any matching results stored in the Remote PACS or VNA.
WADO-URI
The reception of a WADO request will activate the AE. An internal request is sent to the search capabilities of the
DCM4CHEE-WADO-SERVICE. This request is based upon the request parameters or the URL resource end point
from the WADO request. The response is a list of all SOP instances stored on the DCM4CHEE-PACS-ARCHIVE that
match the request parameters. If there are no matching instances, the AE will indicate this in the WADO response.
For all matching instances, the AE will utilize the internal image transfer request to obtain a copy of each instance. If
the request was for retrieval of instances, these instances will be returned. If the request was for retrieval of rendered
instances, then the AE will render each instance and return the rendered results.
WADO-RS
The reception of a WADO request will activate the AE. An internal request is sent to the search capabilities of the
DCM4CHEE-WADO-SERVICE. This request is based upon the request parameters or the URL resource end point
from the WADO request. The response is a list of all SOP instances stored on the DCM4CHEE-PACS-ARCHIVE that
match the request parameters. If there are no matching instances, the AE will indicate this in the WADO response.
For all matching instances, the AE will utilize the internal image transfer request to obtain a copy of each instance. If
the request was for retrieval of instances, these instances will be returned. If the request was for retrieval of rendered
instances, then the AE will render each instance and return the rendered results.
Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure B.4.1-2 apply:
1. Query Worklist
2. Receive Worklist of Modality Scheduled Procedure Steps (MSPS)
3. Select Workitem (MSPS) from Worklist
4. Start acquisition and create MPPS
5. Acquire Images
6. Complete acquisition and finalize MPPS
7. Print acquired images (optional step)
8. Store acquired images and any associated Grayscale Softcopy Presentation State (GSPS) instances.
9. If the Image Manager is configured as an archive device the Storage AE will request Storage Commitment for
the images and associated GSPS instances.
Other workflow situations (e.g., unscheduled procedure steps) will have other sequencing constraints. Printing could
equally take place after the acquired images have been stored. Printing could be omitted completely if no printer is
connected or hard copies are not required.
AE Specifications
SOP Classes
The Storage Application Entity provides Standard Conformance to the following SOP Class(es) :
20 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 21
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
22 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 23
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
These are the default SOP Classes supported. By altering the configuration it is possible to support additional or fewer
SOP Classes.
Association Policies
General
The STORAGE-SCP AE can both accept and propose Association Requests. The STORAGE-SCP AE will accept
Association Requests for the Verification, Storage, and Storage Commitment Push Model Services. It will propose
Associations only for the Storage Commitment Push Model Service. The DICOM standard Application Context Name
for DICOM 3.0 is always accepted and proposed:
Number of Associations
The STORAGE-SCP AE can support multiple simultaneous Associations requested by peer AEs. Each time the
STORAGE-SCP AE receives an Association, a child process will be spawned to process the Verification, Storage, or
Storage Commitment Push Model Service requests. The maximum number of child processes, and thus the maximum
number of simultaneous Associations that can be processed, is set by configuration. The default maximum number
24 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
is 10 in total. This maximum number of simultaneous Associations can be either an absolute number or a maximum
number for each requesting external Application Entity. The latter flexibility can be useful if communication with one
external AE is unreliable and one does not wish hung connections with this AE to prevent Associations with other
client AEs. The STORAGE-SCP AE initiates one Association at a time for sending Storage Commitment Push Model
N-EVENT-REPORTs to peer AEs.
Asynchronous Nature
The STORAGE-SCP AE does not support asynchronous communication (multiple outstanding transactions over a
single Association). The STORAGE-SCP AE does permit an SCU to send multiple Storage Commitment Push Model
Requests before it has sent back any N-EVENT-REPORT Notifications. However, the STORAGE-SCP AE must send
an N-ACTION Response before permitting another N-ACTION Request to be received so the DICOM communication
itself is not truly asynchronous.
Table 4.4: Outstanding Storage Commitment Push Model Requests for STORAGE-SCP AE
Maximum number of outstanding Storage Commitment Requests for which no N-EVENT No Maximum
Notification has been sent Limit
The STORAGE-SCP AE will initiate a new Association if a Storage Commitment Push Model Notification (N-
EVENT-REPORT) cannot be sent back over the original Association used to send the corresponding request. A new
Association will always be requested by the STORAGE-SCP AE in such cases even if the peer AE requests another
Association after the original has been closed (i.e., A peer AE opens an Association and sends some Storage requests
and a Storage Commitment Push Model request. Before the STORAGE-SCP AE can send the Storage Commitment
4.2. AE Specifications 25
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Push Model N-EVEN-REPORT the Association is closed. The peer AE then opens another Association and begins
to send Storage requests. In such a case the STORAGE-SCP AE will always initiate a new Association to send the
N-EVENT-REPORT even though it could send the N-EVENT-REPORT over the new Association opened by the peer
AE). An Association Request is sent to the peer AE that sent the Storage Commitment Push Model request and upon
successful negotiation of the required Presentation Context the outstanding N-EVENT-REPORT is sent. If there are
multiple outstanding N-EVENT-REPORTs to be sent to a single peer AE then the STORAGE-SCP AE will attempt
to send them all over a single Association rather than requesting a new Association for each one. The Association
will be released when all the N-EVENT-REPORTs for the peer AE have been sent. If any type of error occurs during
transmission (either a communication failure or indicated by a Status Code returned by the peer AE) over an open
Association then the transfer of N-EVENT-REPORTs is halted. A new Association will be opened to retry sending
outstanding N-EVENT-REPORTs. The maximum number of times the STORAGE-SCP AE will attempt to resend
an N-EVENT-REPORT is configurable, along with the amount of time to wait between attempts to resend. If the
STORAGE-SCP AE sends a Notification request (N-EVENT-REPORT-RQ) over the original Association opened by
the peer AE but receives a request to close the Association rather than a response to the Notification (N-EVENT-
REPORT-RSP) then this is handled in the same way as if the request to close the Association had been received before
trying to send the Notification request. Thus, the STORAGE-SCP AE will then open a new Association to resend the
Notification request. The STORAGE-SCP AE can be configured to always open a new Association before sending
a Storage Commitment Push Model Notifications (N-EVENT-REPORT), in which case the sequencing illustrated in
figure below will always be followed.
Fig. 4.8: Figure : Sequencing of Activity - Send Storage Commitment Notification Over New Association
The following sequencing constraints illustrated in figure above apply to the STORAGE-SCP AE for handling Storage
Commitment Push Model Requests using a new Association:
1. Peer AE opens an Association with the STORAGE-SCP AE.
2. Peer AE requests Storage Commitment of Composite SOP Instance(s) (peer sends N-ACTION-RQ and
STORAGE-SCP AE responds with N-ACTION-RSP to indicate that it received the request).
3. Peer AE closes the Association before the STORAGE-SCP AE can successfully send the Storage Commitment
Push Model Notification (N-EVENT-REPORT-RQ).
4. STORAGE-SCP AE opens an Association with the peer AE.
5. STORAGE-SCP AE sends Storage Commitment Push Model Notification (N-EVENT-REPORT). More than
one can be sent over a single Association if multiple Notifications are outstanding.
6. STORAGE-SCP AE closes the Association with the peer AE.
The Verification Service as an SCU is only supported as a utility function for Service staff. It is used only as a
diagnostic tool when the STORAGE-SCP AE is failing to open new Associations to send N-EVENT-REPORTs to
peer AEs.
The Storage Application Entity will propose Presentation Contexts for Verification and the Storage Commitment Push
Model SOP Class. The list of proposed Transfer Syntaxes for the Storage Commitment Push Model SOP Class is
configurable. By default, only the Transfer Syntax Implicit VR Little Endian will be proposed.
26 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Table 4.5: Proposed Presentation Contexts of Storage Application Entity by default configuration
Presentation Context Table
Abstract Syntax Transfer Syntax
Role Ext. Neg.
Name UID Name UID
Verification 1.2.840.10008.1.1 Implicit VR Little 1.2.840.10008.1.2 SCU None
Endian
Storage Commitment Push 1.2.840.10008.1.20.1Implicit VR Little 1.2.840.10008.1.2 SCP None
Model Endian
SOP Specific Conformance for Storage Commitment Push Model SOP Class
The associated Activity with the Storage Commitment Push Model service is the communication by the STORAGE-
SCP AE to peer AEs that it has committed to permanently store Composite SOP Instances that have been sent to it.
It thus allows peer AEs to determine whether the DCM4CHEE archive has taken responsibility for the archiving of
specific SOP Instances so that they can be flushed from the peer AE system.
The STORAGE-SCP AE will initiate a new Association to a peer AE that sent a Storage Commitment Push Model
request if the original Association over which this was sent is no longer open. For a detailed explanation of the SOP
specific Behavior of the STORAGE-SCP AE in this case please refer to 4.2.4.4.1.3.3, Storage Commitment Push
Model as an SCP.
Standard conformance is provided to the DICOM Verification Service Class as an SCU. The Verification Service as an
SCU is actually only supported as a diagnostic service tool for network communication issues. It can be used to test
whether Associations can actually be opened with a peer AE that is issuing Storage Commitment Push Model requests
(i.e., to test whether the indicated TCP/IP port and AE Title for sending N-EVENT-REPORT Requests to the peer AE
are truly functional).
The STORAGE-SCP AE accepts Associations only if they have valid Presentation Contexts. If none of the requested
Presentation Contexts are accepted then the Association Request itself is rejected. It can be configured to only accept
Associations with certain hosts (using TCP/IP address) and/or Application Entity Titles. The default behavior of
the STORAGE-SCP AE is to always attempt to send a Storage Commitment Push Model Notification (N-EVENT-
REPORT) over the same Association opened by the peer AE to send the request (N-ACTION). If the STORAGE-
SCP AE receives a request to close the Association either before sending the Notification or before receiving the
corresponding N-EVENT-REPORT-RSP then it will open a new Association to send the Notification. Refer to Section
F.4.2.3.4.1.5 for the details.
Fig. 4.9: Figure : Sequencing of Activity - Receive Images and Storage Commitment Requests
The following sequencing constraints illustrated in figure above apply to the STORAGE-SCP AE for handling Storage
Commitment Push Model Requests over the original Association:
4.2. AE Specifications 27
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The Storage Application Entity will accept Presentation Contexts for all SOP Classes listed in Table 4.2.1.1-1 by
default. The list of accepted Transfer Syntaxes for each accepted Abstract Syntax - as the list of accepted Abstract
Syntaxes itselfs - is configurable.
Table 4.6: Accepted Presentation Contexts of Storage Application Entity by default configuration
Presentation Context Table
Abstract Syntax Transfer Syntax
Role Ext. Neg.
Name UID Name UID
Verification 1.2.840.10008.1.1 Implicit VR Little Endian 1.2.840.10008.1.2 SCP None
Storage Commitment 1.2.840.10008.1.20.1
Implicit VR Little Endian 1.2.840.10008.1.2 SCP None
Push Model
Image Storage SOP Classes in Table 4.1 see Table 4.7 SCP None
Video Storage SOP Classes in Table 4.1 see Table 4.8 SCP None
Implicit VR Little Endian 1.2.840.10008.1.2
SR Storage SOP Classes in Table 4.1 Explicit VR Little Endian 1.2.840.10008.1.2.1 SCP None
Deflated Explicit VR 1.2.840.10008.1.2.1.99
Little Endian
Implicit VR Little Endian 1.2.840.10008.1.2
Other Storage SOP Classes in Table 4.1 SCP None
Explicit VR Little Endian 1.2.840.10008.1.2.1
28 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The Storage Application Entity provides standard conformance to the Verification SOP Class as an SCP.
The associated Activity with the Storage service is the storage of medical image data received over the network on a
designated hard disk. The Storage Application Entity will return a failure status if it is unable to store the images on
to the hard disk.
The Storage Application Entity does not have any dependencies on the number of Associations used to send images
to it. Images belonging to more than one Study or Series can be sent over a single or multiple Associations. Images
belonging to a single Study or Series can also be sent over different Associations. There is no limit on either the
number of SOP Instances or the maximum amount of total SOP Instance data that can be transferred over a single
Association.
The Storage Application Entity retains the original DICOM data in DICOM Part 10 compliant file format. The Storage
Application Entity is Level 2 (Full) conformant as a Storage SCP. In addition, all Private and SOP Class Extended
Elements are maintained in the DICOM format files.
1 Because of known issues of the JPEG 2000 implementation, acceptance of JPEG 2000 is only recommended for production, if all Retrieve
Destinations also accepts JPEG 2000, so the archive does not need to decompress JPEG 2000 images for retrieval.
4.2. AE Specifications 29
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
In addition to saving all Elements in files, a subset of the Elements are stored in the archive database to support query
and retrieval requests and also allow updating of Patient, Study, and Series information by user input, or demographic
and Study related messages.
The behavior for handling duplicate SOP Instances is configurable by selecting one of 5 available Overwrite Policies:
NEVER: Never overwrite stored Instances on receive of a different Instance with equal SOP Instance UID. Ignore
the received instance silently - returning a success status.
ALWAYS: Always overwrite stored Instances by subsequently received Instances with equal SOP Instance UID.
SAME_SOURCE (default): Only overwrite stored Instances by subsequently received Instances with equal SOP
Instance UID, if the new Instance was sent from the same Source Application Entity or HTTP client as the
previous received Instance. Otherwise ignore the received instance silently - returning a success status.
SAME_SERIES: Only overwrite stored Instances by subsequently received Instances with equal SOP Instance UID,
if the new Instance belongs to the same Series as the previous received Instance (= if beside the SOP Instance
UID, also Study and Series Instance UID are equal). Otherwise ignore the received instance silently - returning
a success status.
SAME_SOURCE_AND_SERIES: Only overwrite stored Instances by subsequently received Instances with equal
SOP Instance UID, if the new Instance was sent from the same Source Application Entity or HTTP client as the
previous received Instance, and if the new Instance belongs to the same Series as the previous received Instance
(= if beside the SOP Instance UID, also Study and Series Instance UID are equal). Otherwise ignore the received
instance silently - returning a success status.
The behavior for updating Patient, Study and Series Attributes in the archive database, if there values differs between
received Instances of the same Patient, Study and Series is configurable for each Entity Level by selecting one of 4
Attribute Update Policies:
NONE: Do not update the Attributes of the Entity in the database from its initial values extracted from the first
received Instance of the Entity.
SUPPLEMENT (default for Patient Attributes): Supplement the Attributes of the Entity in the database with At-
tributes of subsequently received Instances which were not present or had no value in previous received Instances
of the same Entity.
MERGE (default for Study and Series Attributes): Overwrite the Attributes of the Entity in the database with non-
empty Attributes from subsequently received Instances of the same Entity.
OVERWRITE: Overwrite the Attributes of the Entity in the database with all Attributes from subsequently received
Instances of the same Entity.
The Storage Application Entity can be configured to compress uncompressed received Image SOP Instances, depen-
dent on the Source Application Entity or HTTP client and dependent of DICOM Attribute values of received SOP
Instances, using one of following Transfer Syntaxes:
By default, no image compression is configured.
30 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Note : If a failure condition does occur when handling an Association then all images previously received successfully
over the Association are maintained in the DCM4CHEE archive database. No previously successfully received images
are discarded. Even if an image is successfully received but an error occurs transmitting the C-STORE Response then
this final image is maintained rather than discarded. If the loss of an Association is detected then the Association is
closed. In the above table, some references to rejection error codes in Refused Service Status is due to the fact that,
when objects are rejected the rejection notes are stored in the database for further processing.
The Behavior of STORAGE-SCP AE during communication failure is summarized in the following table:
The associated Activity with the Storage Commitment Push Model service is the communication by the STORAGE-
SCP AE to peer AEs that it has committed to permanently store Composite SOP Instances that have been sent to it.
It thus allows peer AEs to determine whether the DCM4CHEE archive has taken responsibility for the archiving of
specific SOP Instances so that they can be flushed from the peer AE system. The STORAGE-SCP AE takes the list
of Composite SOP Instance UIDs specified in a Storage Commitment Push Model N-ACTION Request and checks if
they are present in the DCM4CHEE archive database. As long as the Composite SOP Instance UIDs are present in
the database, the STORAGE-SCP AE will consider those Composite SOP Instance UIDs to be successfully archived.
The STORAGE-SCP AE does not require the Composite SOP Instances to actually be successfully written to archive
media in order to commit to responsibility for maintaining these SOP Instances. Once the STORAGE-SCP AE has
checked for the existence of the specified Composite SOP Instances, it will then attempt to send the Notification request
(N-EVENT-REPORT-RQ). The default behavior is to attempt to send this Notification over the same Association that
was used by the peer AE to send the original N-ACTION Request. If the Association has already been released or
Message transfer fails for some reason then the STORAGE-SCP AE will attempt to send the N-EVENT-REPORT-
RQ over a new Association. The STORAGE-SCP AE will request a new Association with the peer AE that made
the original N-ACTION Request. The STORAGE-SCP AE can be configured to always open a new Association in
order to send the Notification request. The STORAGE-SCP AE will not cache Storage Commitment Push Model
N-ACTION Requests that specify Composite SOP Instances that have not yet been transferred to the DCM4CHEE
archive. If a peer AE sends a Storage Commitment Push Model N-ACTION Request before the specified Composite
SOP Instances are later sent over the same Association, the STORAGE-SCP AE will not commit to responsibility
for such SOP Instances. The STORAGE-SCP AE does not support the optional Storage Media File-Set ID & UID
32 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
attributes in the N-ACTION. The DCM4CHEE archive never automatically deletes Composite SOP Instances from
the archive. The absolute persistence of SOP Instances and the maximum archiving capacity for such SOP Instances
is dependent on the archiving media and capacity used by the DCM4CHEE archive and is dependent on the actual
specifications of the purchased system. It is necessary to check the actual system specifications to determine these
characteristics. The STORAGE-SCP AE will support Storage Commitment Push Model requests for SOP Instances of
any of the Storage SOP Classes that are also supported by the STORAGE-SCP AE as given in 4.2.1.1-1.: SOP Classes
for Storage Application Entity (SCP)
The STORAGE-SCP AE will return the following Status Code values in N-ACTION Responses:
Table 4.11: STORAGE-SCP AE Storage Commitment Push Model N-ACTION Response Status Return Behavior
Ser- Further Error Behaviour
vice Mean- Code
Status ing
Success Success 0000 The SCP has successfully received the Storage Commitment Push Model
N-ACTION Request and can process the commitment request for the indicated
SOP Instances.
Error Process- 0110 Indicates that the Storage Commitment Push Model N-ACTION Request cannot
ing be parsed or fully processed due to a database or system failure.
Failure
The STORAGE-SCP AE will exhibit the following Behavior according to the Status Code value returned in an N-
EVENT-REPORT Response from a destination Storage Commitment Push Model SCU:
4.2. AE Specifications 33
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
if an error Status Code is returned or a communication failure occurs. The maximum number of times to attempt
sending as well as the time to wait between attempts is configurable.
SOP Classes
The Query/Retrieve Application Entity provides Standard Conformance to the following SOP Classes:
34 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 35
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
36 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 37
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
These are the default SOP Classes supported. By altering the configuration it is possible to support additional or fewer
SOP Classes.
Association Policies
General
The STORAGE-SCU AE can only form Associations when requested to do so by the DCM4CHEE SCP AE. The
STORAGE-SCU AE can only request the opening of an Association. It cannot accept requests to open Associations
from external Application Entities. The DCM4CHEE SCP AE will never initiate Associations; it only accepts As-
sociation Requests from external DICOM AEs. The DCM4CHEE SCP AE will accept Associations for Verification,
C-FIND, C-GET and C-MOVE requests. In the case of a C-MOVE/C-GET request, the DCM4CHEE SCP AE will
issue a command to the STORAGE-SCU AE to initiate an Association with the Destination DICOM AE to send
images as specified by the originator of the C-MOVE Request. In case of C-GET request the originator is itself the
destination. The DICOM standard Application Context Name for DICOM 3.0 is always proposed (Storage SCU) /
accepted (Query/Retrieve SCP).
Number Of Associations
The maximum number of simultaneous Associations is configurable, but is usually limited to a maximum of 10. This
configuration largely depends on whether relatively quick response to multiple simultaneous C-MOVE Destination
AEs is required or maximum throughput performance is required. If the latter is the case, then no simultaneous
Associations are permitted, in order to reduce disk thrashing and thus maximize throughput. The STORAGE-SCU
AE can initiate simultaneous Associations to a given external C-MOVE Destination AE up to the maximum number
configured. There is no separate limit on the maximum number permitted to the same C-MOVE Destination AE. If the
first attempt to open an Association fails then the STORAGE-SCU AE will reschedule the task to attempt it again after
a configurable time delay. The number of times to reattempt Association establishment is configurable, with the default
38 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
being zero. The DCM4CHEE SCP AE can support multiple simultaneous Associations. Each time the DCM4CHEE
SCP AE receives an Association, a child process will be spawned to process the Verification, Query, or Retrieval
request. The maximum number of child processes, and thus the maximum number of simultaneous Associations that
can be processed, is set by configuration. The default maximum is 10 in total. The maximum number of simultaneous
Associations can be either an absolute number or a maximum number for each requesting external Application Entity.
The latter flexibility can be useful if communication with one external AE is unreliable and one does not wish hung
connections with this AE to prevent Associations with other client AEs.
Asynchronous Nature
The Storage SCU AE and Query/Retrieve SCP AE do not support asynchronous communication (multiple outstanding
transactions over a single Association). All Association requests must be completed and acknowledged before a new
operation can be initiated.
Table 4.15: Asynchronous Nature as a SCU for STORAGE-SCU AE / SCP for Query-
Retrieve SCP AE
Maximum number of outstanding asynchronous transactions 1 (Not Configurable)
The Storage SCU AE will initiate a new Association when the Query/Retrieve SCP AE invokes the Storage SCU AE
to transmit images. The Query/Retrieve SCP AE will issue such a command whenever it receives a valid C-MOVE
Request. An Association Request is sent to the specified C-MOVE Destination AE and upon successful negotiation of
the required Presentation Context the image transfer is started. In all cases an attempt will be made to transmit all the
indicated images in a single Association, but this may not always be possible. The Association will be released when
all the images have been sent. If an error occurs during transmission over an open Association then the image transfer
is halted. The Storage SCU AE will not attempt to independently retry the image export. Note that the Storage SCU
AE does not support the unsolicited sending of SOP Instances using the DICOM Storage Service Class. It will only
send SOP Instances in response to a C-MOVE Request from a peer AE.
Fig. 4.10: Figure : Sequencing of Activity - Send Images Requested By an External Peer AE
4.2. AE Specifications 39
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The following sequencing constraints illustrated in figure above apply to the Storage SCU AE:
1. Peer AE requests retrieval of Study, Series, or Images from Query/Retrieve SCP AE (C-MOVE-RQ).
2. Query/Retrieve SCP AE signals Storage SCU AE to send the image Composite SOP Instances indicated in the
C-MOVE-RQ to the C-MOVE Destination AE.
3. Storage SCU AE opens a new Association with the indicated C-MOVE Destination AE.
4. Storage SCU AE sends the indicated Composite SOP Instances.
5. Storage SCU AE closes the Association.
6. The Verification Service is only supported as a utility function for Service staff. It is used only as a diagnostic
tool.
The Query/Retrieve Application Entity will propose Presentation Contexts for Verification, Study Root Query/Retrieve
Information Model - FIND, Study Root Query/Retrieve Information Model - MOVE and of supported Storage SOP
Classes.
40 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
1.2.840.10008.5.1.4.1.2.2.1
Implicit VR Lit- 1.2.840.10008.1.2 SCU None
tle Endian
Study Root
Query/Retrieve
Information
Model - FIND
1.2.840.10008.5.1.4.1.2.2.2
Implicit VR Lit- 1.2.840.10008.1.2 SCU None
tle Endian
Study Root
Query/Retrieve
Information
Model - MOVE
Image Storage SOP Class in Table 4.13 Table 4.17 SCU None
Video Storage SOP Class in Table 4.13 Table 4.18 SCU None
Implicit VR Lit- 1.2.840.10008.1.2
SR Storage SOP Class in Table 4.13 tle Endian SCU None
Explicit VR Lit- 1.2.840.10008.1.2.1
tle Endian
Deflated Ex- 1.2.840.10008.1.2.1.99
plicit VR Little
Endian
Implicit VR Lit- 1.2.840.10008.1.2
Other Storage SOP Class in Table 4.13 SCU None
tle Endian
Explicit VR Lit- 1.2.840.10008.1.2.1
tle Endian
4.2. AE Specifications 41
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Standard conformance is provided to the DICOM Verification Service Class as an SCU. The Verification Service as
an SCU is actually only supported as a diagnostic service tool for network communication issues.
Composite DICOM SOP Instances are maintained as DICOM Part 10 compliant files in the DCM4CHEE archive
database. The entire set of tags received with the image will be saved in DCM4CHEE archive; this includes all Private
and SOP Extended Elements. When a SOP Instance is selected for export from DCM4CHEE archive, its content
will be exported as it was originally received except for a few possible exceptions. Some of the Patient demographic
and Study information Elements whose values can have been altered due to changes administered on DCM4CHEE
archive or changes to the state of the image data due to compression can be altered when the SOP Instance is exported.
The Patient demographic and Study information can be entered or altered by several means: manually, or from HL7
messaging,. The replacement behavior depends on which specific DICOM and HL7 services are supported. Also,
this behavior is configurable. Values can be altered without changing the SOP Instance UID unless otherwise noted.
Refer to the Annex for the specific details of which Elements can have their values altered at time of export. The
DCM4CHEE archive creates files called Service Logs that can be used to monitor their status and diagnose any
problems that may arise. If any error occurs during DICOM communication then appropriate messages are always
output to these Service Logs. In addition, error messages may be output as alerts to the User Interface in certain cases.
The Storage SCU AE will exhibit the following Behavior according to the Status Code value returned in a C-STORE
Response from a destination C-STORE SCP:
42 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
All Status Codes indicating an error or refusal are treated as a permanent failure. The STORAGE-SCU AE never
automatically resends images when an error Status Code is returned in a C-STORE Response. For specific behavior
regarding Status Code values returned in C-MOVE Responses, refer to the Services Supported as an SCP by the
DCM4CHEE SCP AE.
The Query/Retrieve SCP AE accepts Associations only if they have valid Presentation Contexts. If none of the re-
quested Presentation Contexts are accepted then the Association Request itself is rejected. It can be configured to only
accept Associations with certain hosts (using TCP/IP address) and/or Application Entity Titles. If Query/Retrieve SCP
AE receives a query (C-FIND) request then the response(s) will be sent over the same Association used to send the C-
FIND-Request. If Query/Retrieve SCP AE receives a retrieval (C-MOVE) request then the responses will be sent over
the same Association used to send the C-MOVE-Request. The Query/Retrieve SCP AE will notify the Storage SCU
to send the requested SOP Instances to the C-MOVE Destination. The Storage SCU AE notifies the Query/Retrieve
SCP AE of the success or failure of each attempt to send a Composite SOP Instance to the peer C-MOVE Destination
AE. The Query/Retrieve SCP AE then sends a C-MOVE Response indicating this status after each attempt. Once
the Storage SCU AE has finished attempting to transfer all the requested SOP Instances, the Query/Retrieve SCP AE
sends a final C-MOVE Response indicating the overall status of the attempted retrieval.
Fig. 4.11: Figure : Sequencing of Activity - Handling Query and Retrieval Requests
The following sequencing constraints illustrated in above figure apply to the DCM4CHEE SCP AE for handling
queries (C-FIND-Requests) :
1. Peer AE opens an Association with the Query/Retrieve SCP AE.
2. Peer AE sends a C-FIND-RQ Message
44 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
3. Query/Retrieve SCP AE returns a C-FIND-RSP Message to the peer AE with matching information. A C-FIND-
RSP is sent for each entity matching the identifier specified in the C-FIND-RQ. A final C-FIND-RSP is sent
indicating that the matching is complete.
4. Peer AE closes the Association. Note that the peer AE does not have to close the Association immediately.
Further C-FIND or C-MOVE Requests can be sent over the Association before it is closed.
The following sequencing constraints illustrated in above figure apply to the DCM4CHEE SCP AE for handling
retrievals (C-MOVE-Requests) :
1. Peer AE opens an Association with the Query/Retrieve SCP AE.
2. Peer AE sends a C-MOVE-RQ Message
3. Query/Retrieve SCP AE notifies the Storage SCU AE to send the Composite SOP Instances to the peer C-MOVE
Destination AE as indicated in the C-MOVE-RQ.
4. After attempting to send a SOP Instance, the Storage SCU AE indicates to the Query/Retrieve SCP AE whether
the transfer succeeded or failed. The Query/Retrieve SCP AE then returns a C-MOVE-RSP indicating this
success or failure.
5. Once the Storage SCU AE has completed all attempts to transfer the SOP Instances to the C-MOVE Destination
AE, or the first failure occurred, the Query/Retrieve SCP AE sends a final C-MOVE-RSP indicating the overall
success or failure of the retrieval.
6. Peer AE closes the Association. Note that the peer AE does not have to close the Association immediately.
Further C-FIND or C-MOVE Requests can be sent over the Association before it is closed.
The Query/Retrieve SCP AE may reject Association attempts as shown in the table below. The Result, Source and
Reason/Diag columns represent the values returned in the corresponding fields of an ASSOCIATE-RJ PDU. The
following abbreviations are used in the Source column:
1. 1 - DICOM UL service-user
2. 2 - DICOM UL service-provider (ASCE related function)
3. 3 - DICOM UL service-provider (Presentation related function)
The Query/Retrieve Application Entity will accept Presentation Contexts for all SOP Classes listed in Table 4.2.1.1-1
by default. The list of accepted Transfer Syntaxes for each accepted Abstract Syntax - as the list of accepted Abstract
Syntaxes itselfs - is configurable.
The Query/Retrieve SCP AE supports hierarchical queries and not relational queries. There are no attributes always
returned by default. Only those attributes requested in the query identifier are returned. Query responses always return
values from the DCM4CHEE archive database. Exported SOP Instances are always updated with the latest values in
the database prior to export. Thus, a change in Patient demographic information will be contained in both the C-FIND
Responses and any Composite SOP Instances exported to a C-MOVE Destination AE. Patient Root Information Model
All required search keys on each of the four levels (Patient, Study, Series, and Image) are supported. However, the
Patient ID (0010,0020) key must have at least a partial value if the Patients Name (0010,0010) is not present in a
Patient Level query. Study Root Information Model All the required search keys on each of the three levels (Study,
Series, and Image) are supported. If no partial values are specified for Study attributes then either the Patient ID
(0010,0020) key or the Patients Name (0010,0010) must have at least a partial value specified.
4.2. AE Specifications 45
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
46 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 47
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The Query/Retrieve SCP AE will convey to the Storage SCU AE that an Association with a DICOM Application
Entity named by the external C-MOVE SCU (through a MOVE Destination AE Title) should be established. It will
also convey to the Storage SCU AE to perform C-STORE operations on specific images requested by the external
C-MOVE SCU. One or more of the Image Storage Presentation Contexts listed in Table 4.2.2.3-1. will be negotiated.
The Query/Retrieve SCP AE can support lists of UIDs in the C-MOVE Request at the Study, Series, and Image Levels.
The list of UIDs must be at the Level of the C-MOVE Request however. For example, if the C-MOVE Request is for
Series Level retrieval but the identifier contains a list of Study UIDs then the C-MOVE Request will be rejected, and
the A900 Failed Status Code will be returned in the C-MOVE Response. An initial C-MOVE Response is always sent
after confirming that the C-MOVE Request itself can be processed. After this, the Query/Retrieve SCP AE will return
a response to the C-MOVE SCU after the Storage SCU AE has attempted to send each image. This response reports
the number of remaining SOP Instances to transfer, and the number transferred having a successful, failed, or warning
status. If the Composite SOP Instances must be retrieved from long-term archive prior to export there may be quite
a long delay between the first C-MOVE Response and the next one after the attempt to export the first image. The
maximum length of time for this delay will depend on the particular type of archive used but typically varies between
3 and 10 minutes.
Note that the Warning Status, B000 (Sub-operations complete - One or more Failures) is never returned. If a failure
occurs during export to the C-MOVE Destination AE by the STORAGE-SCU AE then the entire task is aborted. Thus
any remaining matches are not exported.
48 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
SOP Classes
The Workflow Application Entity provides Standard Conformance to the following SOP Class(es) :
Association Policies
General
The DICOM standard application context name for DICOM 3.0 is always proposed:
Number of Associations
4.2. AE Specifications 49
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Asynchronous Nature
The Workflow AE does not support asynchronous communication (multiple outstanding transactions over a single
Association).
The request for a Worklist Update is initiated by user interaction, i.e., pressing the buttons Worklist Update/Patient
Worklist Query or automatically at specific time intervals, configurable by the user. With Worklist Update the
automated query mechanism is performed immediately on request, while with Patient Worklist Query a dialog to
enter search criteria is opened and an interactive query can be performed. The interactive Patient Worklist Query will
display a dialog for entering data as search criteria. When the Query is started on user request, only the data from
the dialog will be inserted as matching keys into the query. With automated worklist queries (including Worklist
Update) the Worklist Application Entity always requests all items for a Scheduled Procedure Step Start Date (actual
date), Modality (RF) and Scheduled Station AE Title. Query for the Scheduled Station AE Title is configurable by
a Service Engineer. Upon initiation of the request, the Worklist Application Entity will build an Identifier for the
C-FIND request, will initiate an Association to send the request and will wait for Worklist responses. After retrieval of
all responses, Worklist Application Entity will access the local database to add or update patient demographic data. To
protect the system from overflow, the Worklist Application Entity will limit the number of processed worklist responses
to a configurable maximum. During receiving the worklist response items are counted and the query processing is
canceled by issuing a C-FIND-CANCEL if the configurable limit of items is reached. The results will be displayed
in a separate list, which will be cleared with the next worklist update. Worklist Application Entity will initiate an
Association in order to issue a C-FIND request according to the Modality Worklist Information Model.
A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g., a device such as a
RIS or HIS that supports the Modality Worklist SOP Class as an SCP) is illustrated in the Figure above:
1. The Worklist AE opens an association with the Departmental Scheduler
2. The Worklist AE sends a C-FIND request to the Departmental Scheduler containing the Worklist Query at-
tributes.
50 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
3. The Departmental Scheduler returns a C-FIND response containing the requested attributes of the first matching
Worklist Item.
4. The Departmental Scheduler returns another C-FIND response containing the requested attributes of the second
matching Worklist Item. 5. The Departmental Scheduler returns another C-FIND response with status Success in-
dicating that no further matching Worklist Items exist. This example assumes that only 2 Worklist items match the
Worklist Query. 6. The Worklist AE closes the association with the Departmental Scheduler. 7. The user selects a
Worklist Item from the Worklist and prepares to acquire new images.
After Patient registration, the Modality is awaiting the 1st application of X-Ray Dose to the patient. The trigger to
create a MPPS SOP Instance is derived from this event. An Association to the configured MPPS SCP system is estab-
lished immediately and the related MPPS SOP Instance will be created. A manual update can be performed with the
MPPS user interface where is it possible to set the final state of the MPPS to COMPLETED or DISCONTINUED.
In the Discontinued case the user can also select the discontinuation reason. A MPPS Instance that has been sent
with a state of COMPLETED or DISCONTINUED can no longer be updated. The Modality will support creation
of unscheduled cases by allowing MPPS Instances to be communicated for locally registered Patients. The Modality
only supports a 0-to-1 relationship between Scheduled and Performed Procedure Steps. The Modality will initiate an
Association to issue an:
1. N-CREATE request according to the CREATE Modality Performed Procedure Step SOP Instance operation or
a
2. N-SET request to update the contents and state of the MPPS according to the SET Modality Performed Proce-
dure Step Information operation.
A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g., a device such as a
RIS or HIS that supports the MPPS SOP Class as an SCP) is illustrated in above figure.
1. The Worklist AE opens an association with the Departmental Scheduler
2. The Worklist AE sends an N-CREATE request to the Departmental Scheduler to create an MPPS instance with
status of IN PROGRESS and create all necessary attributes. The Departmental Scheduler acknowledges the
MPPS creation with an N-CREATE response (status success).
3. The Worklist AE closes the association with the Departmental Scheduler.
4. All images are acquired and stored in the local database.
5. The Worklist AE opens an association with the Departmental Scheduler.
6. The Worklist AE sends an N-SET request to the Departmental Scheduler to update the MPPS instance with
status of COMPLETED and set all necessary attributes. The Departmental Scheduler acknowledges the MPPS
update with an N-SET response (status success).
7. The Worklist AE closes the association with the Departmental Scheduler.
The Workflow AE will propose Presentation Contexts as shown in the following table:
4.2. AE Specifications 51
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The behavior of modality worklist when encountering status codes in a Modality Worklist C-FIND response is sum-
marized in the Table below. If any other SCP response status than Success or Pending is received by modality
worklist, a message query failed will appear on the user interface.
52 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The behavior when encountering status codes in an MPPS N-CREATE or N-SET response is summarized in table
below. If any other SCP response status than Success or Warning is received, a message MPPS update failed
will appear on the user interface.
54 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Acquired images will always use the Study Instance UID specified for the Scheduled Procedure Step (if available). If
an acquisition is unscheduled, a Study Instance UID will be generated locally. The Table below provides a description
of the Modality Worklist Request Identifier and specifies the attributes that are copied into the images. Unexpected
attributes returned in a C-FIND response are ignored. Requested return attributes not supported by the SCP are set to
have no value. Non-matching responses returned by the SCP due to unsupported optional matching keys are ignored.
No attempt is made it filter out possible duplicate entries.
Module Name
Attribute Tag VR M R Q D IOD
Name
Scheduled Procedure Step
Scheduled (0040,0100)
Proce-
dure Step
Sequence
>Scheduled (0040,0001) AE x
Station 19.
AET
>Scheduled (0040,0002) DA S x
Procedure
Step Start
Date
>Scheduled (0040,0003) TM x x
Procedure
Step Start
Time
>Modality (0008,0060) CS S x x
>Scheduled (0040,0006) PN x x x x
Performing
Physicians
Name
>Scheduled (0040,0007) LO x x x
Procedure
Step De-
scription
>Scheduled (0040,0010) SH x x
Station
Name
>Scheduled (0040,0011) SH x x
Procedure
Step Loca-
tion
>Scheduled (0040,0008) SQ x x x
Protocol
Code
Sequence
>Pre- (0040,0012) LO x x
Medication
>Scheduled (0040,0009) SH x x x
Procedure
Step ID
Continued on next page
4.2. AE Specifications 55
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
56 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 57
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
9. IOD : An x indicates that this Worklist attribute is included into all Object Instances created during perfor-
mance of the related Procedure Step.
The default Query Configuration is set to Modality (RF) and Date (date of today). Optionally, additional matching
for the own AET is configurable. Below table provides a description of the MPPS N-CREATE and N-SET request
identifiers sent. Empty cells in the N-CREATE and N-SET columns indicate that the attribute is not sent. An x
indicates that an appropriate value will be sent. A Zero length attribute will be sent with zero length.
58 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
STOW-RS Specifications
Connection Policies
General
All standard RS connection policies apply. There are no extensions for RS options.
Number Of Connections
DCM4CHEE-STOW-SERVICE limits the number of simultaneous RS requests. Additional requests will be queued
after the HTTP connection is accepted. When an earlier request completes, a pending request will proceed.
Asynchronous Nature
4.2. AE Specifications 59
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
The DCM4CHEE-STOW-SERVICE response message header contains status codes indicating success, warning, or
failure as shown in the HTTP Standard Response Codes below. No additional status codes are used.
QIDO-RS Specifications
Attributes Names Tag Query Keys Matching (SCP) Return Attributes (SCP)
Study Instance UID 0002000D UNIQUE UNIQUE
Study ID 00020010 S,*,U S,*,U
Study Date 00080020 S,*,U,R S,*,U,R
Study Time 00080030 S,*,U,R S,*,U,R
Continued on next page
60 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Types of Matching :
1. S indicates the identifier attribute uses Single Value Matching.
2. L indicates UID List Matching.
3. U indicates Universal Matching. (Note : If only Universal Matching is supported for an attribute then that
attribute can only be passed as an includefield query key.)
4. * indicates wild card matching.
5. R indicates Range Matching.
6. SEQUENCE indicates Sequence Matching.
7. NONE indicates that no matching is supported, but that values for this Element requested will be returned
with all requests.
8. UNIQUE indicates that this is the Unique Key for that query level, in which case Universal Matching or Single
Value Matching is used depending on the query level.
4.2. AE Specifications 61
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Attributes Names Tag Query Keys Matching (SCP) Return Attributes (SCP)
Series Instance UID 0002000E UNIQUE UNIQUE
Series Number 00200011 S,*,U S,*,U
Modality 00080060 S,*,U S,*,U
Body Part Examined 00180015 S,*,U S,*,U
Performed Procedure Step Start Date 00400244 S,*,U,R S,*,U,R
Performed Procedure Step Start Time 00400245 S,*,U,R S,*,U,R
Performing Physician Name 00081050 S,*,U S,*,U
Station Name 00081010 S,*,U S,*,U
Series Description 0008103E S,*,U S,*,U
Institutional Department Name 00081040 S,*,U S,*,U
Institution Name 00080080 S,*,U S,*,U
Request Attributes Sequence 00400275 SEQUENCE SEQUENCE
>Accession Number 00080050 S,*,U S,*,U
>Issuer of Accession Number 00080051
>Requesting Service 00321033 S,*,U S,*,U
>Requesting Physician 00321032 S,*,U S,*,U
>Requested Procedure ID 00401001 S,*,U S,*,U
>Study Instance UID 0002000D UNIQUE UNIQUE
>Scheduled Procedure ID 00400009 S,*,U S,*,U
Institution Code Sequence 00080082 SEQUENCE SEQUENCE
>Code Value 00080100 S,*,U S,*,U
>Coding Scheme Designator 00080102 S,*,U S,*,U
>Coding Scheme Version 00080103 S,*,U S,*,U
Sending Application Entity Title of Series S,*,U
Failed SOP Instance UID List 00080058 L
Laterality 00200060 NONE
Manufacturer 00080070 NONE
Manufacturer Model Name 00081090 NONE
Referenced Performed Procedure Step Sequence 00081111 NONE
Specific Character Set 00080005 NONE
Retrieve URL 00081190 NONE
Retrieve AE Title 00080054 NONE
Instance Availability 00080056 NONE
Continued on next page
62 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Attributes Names Tag Query Keys Matching (SCP) Return Attributes (SCP)
SOP Class UID 00080016 L L
SOP Instance UID 00080018 UNIQUE UNIQUE
Content Date 00080023 S,*,U,R S,*,U,R
Content Time 00080033 S,*,U,R S,*,U,R
Instance Number 00200013 S,*,U S,*,U
Concept Name Code Sequence 0040A043 SEQUENCE SEQUENCE
>Code Value 00080100 S,*,U S,*,U
>Coding Scheme Designator 00080102 S,*,U S,*,U
>Coding Scheme Version 00080103 S,*,U S,*,U
Verifying Observer Sequence 0040A073 SEQUENCE SEQUENCE
>Verifying Observer Name 0040A075 S,*,U S,*,U
>Verification Date Time 0040A030 S,*,U, R S,*,U, R
Completion Flag 0040A491 S,*,U S,*,U
Verification Flag 0040A493 S,*,U S,*,U
Content Sequence 0040A730 SEQUENCE SEQUENCE
>Value Type 0040A040 S S
>Concept Name Code Sequence 0040A043 SEQUENCE SEQUENCE
>>Code Value 00080100 S,*,U S,*,U
>>Coding Scheme Designator 00080102 S,*,U S,*,U
>>Coding Scheme Version 00080103 S,*,U S,*,U
>Relationship Type 0040A010 S,*,U S,*,U
>Concept Code Sequence 0040A168 SEQUENCE SEQUENCE
>>Code Value 00080100 S,*,U S,*,U
>>Coding Scheme Designator 00080102 S,*,U S,*,U
>>Coding Scheme Version 00080103 S,*,U S,*,U
>Text Value 0040A160 S,*,U S,*,U
Image Type 00080008 NONE
Observation Date Time 0040A032 NONE
Continued on next page
4.2. AE Specifications 63
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Attributes Names Tag Query Keys Matching (SCP) Return Attributes (SC
Patient Name 00100010 S,*,U S,*,U
Patient ID 00100020 S,*,U S,*,U
Patient Birth Date 00100030 S,*,U,R S,*,U,R
Patient Sex 00100040 S,*,U S,*,U
Issuer of Patient ID 00100021 S,*,U S,*,U
Issuer of Patient ID Qualifier Sequence 00100024 NONE
Patient Birth Time 00100032 NONE
Patient Insurance Plan Code Sequence 00100050 NONE
Patient Primary Language Code Sequence 00100101 NONE
Continued on next pa
64 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Extended Negotiation :
4.2. AE Specifications 65
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
DCM4CHEE-QIDO-SERVICE does not support the fuzzymatching query key. DCM4CHEE-QIDO-SERVICE will
perform case insensitive matching for PN VR attributes but will not perform other forms of fuzzy matching. This
applies to the following attributes:
Table 4.37 Referring Physicians Name (0008,0090).
Patients Name (0010,0010).
Physicians of Record (0008,1048).
Table 4.39 Performing Physicians Name (0008,1050).
Table 4.41 Verifying Observer Name (0040,A075).
Table 4.43 Patients Name (0010,0010).
General
All standard RS connection policies apply. There are no extensions for RS options.
Number Of Connections
DCM4CHEE-QIDO-SERVICE limits the number of simultaneous RS requests. Additional requests will be queued
after the HTTP connection is accepted. When an earlier request completes, a pending request will proceed.
Asynchronous Nature
Response Status
DCM4CHEE-QIDO-SERVICE shall provide a response message header containing the appropriate status code indi-
cating success, warning, or failure as shown below
66 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
WADO-URI Specification
Not Supported
4.2. AE Specifications 67
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
General
All URI connections are limited to HTTP GET requests. The DCM4CHEE-WADO-SERVICE ignores all unknown
HTTP header parameters.
Number Of Connections
Asynchronous Nature
WADO-RS Specifications
68 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.2. AE Specifications 69
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
General
All standard RS connection policies apply. There are no extensions for RS options.
Number Of Connections
DCM4CHEE-WADO-SERVICE limits the number of simultaneous RS requests. Additional requests will be queued
after the HTTP connection is accepted. When an earlier request completes, a pending request will proceed.
Asynchronous Nature
Network Interfaces
The application is indifferent to the physical medium over which TCP/IP executes, which is dependent on the under-
lying operating system and hardware
Additional Protocols
When host names rather than IP addresses are used in the configuration properties to specify presentation addresses
for remote AEs, the application is dependent on the name resolution mechanism of the underlying operating system.
This product supports both IPv4 and IPv6. It does not utilize any of the optional configuration identification or security
features of IPv6.
70 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Configuration
Local AE Titles
The mapping from AE Title to TCP/IP addresses and ports is configurable and set at the time of installation by
Installation Personnel.
The mapping of external AE Titles to TCP/IP addresses and ports is configurable and set at the time of installation
by Installation Personnel. This mapping is necessary for resolving the IP address and port of C-MOVE Destination
Application Entities and must be correctly configured for the DCM4CHEE SCP AE to correctly function as a C-MOVE
SCP.
Parameters
Device
4.4. Configuration 71
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
72 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Network Connection
4.4. Configuration 73
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
74 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Table 4.56: dcm4che Network Connection Attributes Attributes (LDAP Object: dcmDcmNetworkConnection)
Name Type Description LDAP Attribute
Protocol string Protocol of Network Connection. Enumerated values: dcmProtocol
DICOM, HL7, SYSLOG_TLS or SYSLOG_UDP
HTTP Proxy string HTTP Proxy: [user:password@]host:port dcmHTTPProxy
TLS Need Client Auth boolean Indicates if TLS client authentication is required. dcmTLSNeedClientAuth
TLS Protocol(s) string The Supported TLS Protocols. Enumerated values: dcmTLSProtocol
TLSv1.2, TLSv1.1, TLSv1 or SSLv3
TCP Backlog integer Maximum queue length for incoming TCP connections. dcmTCPBacklog
0 = unlimited
TCP Connect Timeout integer TCP connect timeout in ms; no timeout if absent dcmTCPConnectTimeout
TCP Close Delay integer TCP socket close delay in ms after send of A- dcmTCPCloseDelay
ASSOCIATE-RJ, A-RELEASE-RP or A-ABORT PDU.
TCP Send Buffer Size integer TCP send buffer size; use system defaults if absent dcmTCPSendBufferSize
TCP Receive Buffer Size integer TCP receive buffer size; use system defaults if absent dcmTCPReceiveBufferSize
TCP No Delay boolean Enable/disable TCP_NODELAY (disable/enable Nagle dcmTCPNoDelay
algorithm).
Bind Address string Bind address of listening socket; use hostname of the dcmBindAddress
connection if absent
Client Bind Address string Bind address of outgoing connections; use hostname of dcmClientBindAddress
the connection if absent
Blacklisted Hostname(s) string blacklisted DNS hostnames dcmBlacklistedHostname
Send PDU Length integer Maximal length of emitted PDUs. dcmSendPDULength
Receive PDU Length integer Maximal length of received PDUs. dcmReceivePDULength
Max Ops Performed integer Maximal number of operations to perform asyn- dcmMaxOpsPerformed
chronously; 0 = infinite.
Max Ops Invoked integer Maximal number of operations to invoke asyn- dcmMaxOpsInvoked
chronously; 0 = infinite.
Pack PDV boolean Enable/disable packing of command and data PDVs into dcmPackPDV
one P-DATA-TF PDU.
AA-RQ Timeout integer Timeout in ms for receive of A-ASSOCIATE-RQ PDU dcmAARQTimeout
after TCP connect; no timeout if absent
AA-AC Timeout integer Timeout in ms for receive of A-ASSOCIATE-AC PDU dcmAAACTimeout
after send of A-ASSOCIATE-RQ PDU; no timeout if ab-
sent
AR-RP Timeout integer Timeout in ms for receive of A-RELEASE-RP PDU after dcmARRPTimeout
send of A-RELEASE-RQ PDU; no timeout if absent
Response Timeout integer Timeout in ms for receive of response message; no time- dcmResponseTimeout
out if absent
Retrieve Timeout integer Timeout in ms for receive of C-GET-RSP or C-MOVE- dcmRetrieveTimeout
RSP; no timeout if absent
Idle Timeout integer Indicates aborting of idle Associations after specified dcmIdleTimeout
timeout in ms; no timeout if absent
Network AE
4.4. Configuration 75
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Transfer Capability
Each transfer capability specifies the SOP class that the Network AE can support, the mode that it can utilize (SCP or
SCU), and the Transfer Syntax(es) that it can utilize
76 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Archive Network AE
4.4. Configuration 77
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
78 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 79
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
80 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 81
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
HL7 Application
82 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Image Writer
Specifies Java Image IO Image Writer and Write Parameter used for compressing DICOM images
4.4. Configuration 83
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Image Reader
Specifies Java Image IO Image Readers used for decompressing compressed DICOM images
Audit Logger
84 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Archive Device
86 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 87
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
88 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 89
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
90 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 91
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
92 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 93
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
94 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Attribute Filter
4.4. Configuration 95
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Attribute Set
Named Attribute Set for Query Parameter comparefield of DIFF-RS and Query Parameter includefields of WADO-
RS Metadata requests.
Storage
Storage Descriptor
96 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Queue
4.4. Configuration 97
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Exporter Descriptor
Exporter Descriptor
Export Rule
Export Rule
98 Chapter 4. Networking
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
4.4. Configuration 99
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
Rejection Note
Table 4.83: Store Access Control ID Rule Attributes (LDAP Object: dcmStoreAccessControlIDRule)
Name Type Description LDAP Attribute
Name string Arbitrary/Meaningful name of the Store Access Control cn
ID Rule
Store Access Control ID string Access Control ID assigned to Studies which attributes dcmStoreAccessControlID
match all conditions
Rule Priority integer Rule Priority. dcmRulePriority
Conditions(s) string Conditions in format {attributeID}[!]={regEx} dcmProperty
ID Generator
ID Generator
Table 4.86: Scheduled Station for HL7 Order Attributes (LDAP Object: hl7OrderScheduledStation)
Name Type Description LDAP Attribute
Name string Arbitrary/Meaningful name for the Scheduled Station Or- cn
der Mapping
Scheduled Station Device string The DN of a dicomDeviceObject referenced by hl7OrderScheduledStationDevic
Reference hl7OrderScheduledStation
Mapping Priority integer Mapping Priority. dcmRulePriority
Conditions(s) string Conditions in format {attributeID}[!]={regEx} or MSH- dcmProperty
#[!]={regEx}
Specifies SPS Status of DICOM MWL items created/updated on received HL7 ORM^O01, OMI^O23, OMG^O19
messages
Table 4.87: SPS Status for HL7 Order Attributes (LDAP Object: hl7OrderSPSStatus)
Name Type Description LDAP Attribute
Scheduled Procedure Step string Scheduled Procedure Step Status code Enumerated dcmSPSStatus
Status code values: SCHEDULED, ARRIVED, READY, STARTED,
DEPARTED, CANCELLED, DISCONTINUED or
COMPLETED
HL7 Order Control Status(s) string HL7 Order Control Status Code combinations. Enu- hl7OrderControlStatus
merated values: NW_SC, NW_IP, CA_CA, DC_CA,
XO_SC, XO_CM, SC_CM, SC_DC, SC_IP or SC_A
Media Interchange
105
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
dcm4che DICOM Archive 5 supports all extended character sets defined in the DICOM 2017 standard, including
single-byte and multi-byte character sets as well as code extension techniques using ISO 2022 escapes in DICOM
messages.
Support extends to correctly decoding and displaying the correct symbol for all names and strings found in storage
instances received over the network, and in the local database.
In addition to the default character repertoire, the Defined Terms for Specific Character Set in Table 6.1 are supported:
Character Set Description DICOM attribute: Specific Character Set (0008,0005) HL7 field: Character Set MSH 18
Latin alphabet No. 1 ISO_IR 100 8859/1
Latin alphabet No. 2 ISO_IR 101 8859/2
Latin alphabet No. 3 ISO_IR 109 8859/3
Latin alphabet No. 4 ISO_IR 110 8859/4
Cyrillic ISO_IR 144 8859/5
Arabic ISO_IR 127 8859/6
Greek ISO_IR 126 8859/7
Hebrew ISO_IR 138 8859/8
Latin alphabet No. 5 ISO_IR 148 8859/9
Japanese ISO_IR 13 ISO IR14
Thai ISO_IR 166 CNS 11643-1992
Default repertoire ISO 2022 IR 6 not supported1
Latin alphabet No. 1 ISO 2022 IR 100 not supported1
Latin alphabet No. 2 ISO 2022 IR 101 not supported1
Latin alphabet No. 3 ISO 2022 IR 109 not supported1
Latin alphabet No. 4 ISO 2022 IR 110 not supported1
Cyrillic ISO 2022 IR 144 not supported1
Arabic ISO 2022 IR 127 not supported1
Greek ISO 2022 IR 126 not supported1
Continued on next page
107
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
1 Escape sequences supporting multiple character sets in HL7 v2 messages are not supported.
Security
Security Profiles
dcm4che DICOM Archive 5 supports the Basic TLS Secure Transport Connection Profile and the AES TLS Secure
Transport Connection Profile as specified in DICOM Standard, Part 15, Annex B.1 and Annex B.3.
By default configuration, TLS 1.0, TLS 1.1 and TLS 1.2 are enabled, use of TLS 1.2 is preferred.
Also other cyphersuite options than the two in compliance with AES TLS Secure Transport Connection Profile:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
may be configured.
Beside DICOM DIMSE service connections, also HL7 v2 and HTTP connections can be secured by use of TLS.
IP ports on which an implementation accepts TLS connections are configurable.
The private key and the Certificate used by an instance of dcm4che DICOM Archive 5 to identify itself in the TLS
negotiation with remote applications has to be provided in a local keystore file in PKCS12 or JKS (Java Key Store)
format on the application host. Certficates of Certificate Authorities (CA) to validate Certificates received from remote
applications during the TLS negotiation can also be provided in a local keystore file in JKS format or at the central
LDAP server, used as configuration backend for all instances of dcm4che DICOM Archive 5.
dcm4che DICOM Archive 5 supports the Basic Network Address Management Profile as DHCP Client and DNS Client
actor utilizing network configuration options of the underlying operating system. S. DICOM Standard, Part 15, Annex
F.1.
109
DICOM Conformance Statement dcm4che Archive 5, Release 5.10.1
dcm4che DICOM Archive 5 supports the Basic Time Synchronization Profile as DHCP Client and NTP Client actor
utilizing time synchronization options of the underlying operating system. S. DICOM Standard, Part 15, Annex G.1.
dcm4che DICOM Archive 5 supports the Application Configuration Management Profile as LDAP Client actor. Any
LDAP v3 compatible LDAP server can be used as configuration backend for multiple instances of dcm4che DICOM
Archive 5 - and may also be shared with external DICOM applications which also supports the Application Configu-
ration Management Profile as LDAP Client actor. S. DICOM Standard, Part 15, Annex H.1.
dcm4che DICOM Archive 5 supports the Audit Trail Message Format Profile as specified in DICOM Standard, Part
15, Annex A.5.
Audit Messages
Message Structure
Event
Active Participant (1..N)
Audit Source
Participant Object (0..N)
Application Activity
Trigger Events
This audit message is emitted when the archive is started or stopped using the archive user interface. Its is also emitted
during archive startup or shutdown.
Message Structure
Sample Message
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
This message describes the event of a system beginning to transfer a set of DICOM instances from one node to
another node within control of the systems security domain. This message may only include information about a
single patient.
Trigger Events
This message is emitted by the archive in following cases : - Q/R Move : Objects of a study are retrieved using
query/retrieve service and stored to external destination - Q/R Get : Objects of a study are retrieved using query/retrieve
service and stored to the destination which is same as source - Export : Objects of a study are exported - WADO RS :
Objects of a study are retrieved using WADO RESTful service - XDSI Retrieve Imaging Document Set RAD-69
Message Structure
Sample Message
<StudyIDs UID=1.3.12.2.1107.5.2.33.37113.30000008060311320917100000013/>
</ParticipantObjectContainsStudy>
</ParticipantObjectDescription>
</ParticipantObjectIdentification>
<ParticipantObjectIdentification ParticipantObjectID=P5^^^ISSUER ParticipantObject-
TypeCode=1 ParticipantObjectTypeCodeRole=1>
<ParticipantObjectIDTypeCode csd-code=2 originalText=Patient Number
codeSystemName=RFC-3881/>
<ParticipantObjectName>TEST^Name</ParticipantObjectName>
</ParticipantObjectIdentification>
</AuditMessage>
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
Trigger Events
This message is emitted by the archive in following cases : - Q/R Move : Objects of a study are retrieved using
query/retrieve service and stored to external destination - Q/R Get : Objects of a study are retrieved using query/retrieve
service and stored to the destination which is same as source - Export : Objects of a study are exported - WADO RS
: Objects of a study are retrieved using WADO RESTful service - Store : Objects of a study are being stored to the
archive - Storage Commitment of objects of study - XDSI Retrieve Imaging Document Set RAD-69
Message Structure
Sample Message
<StudyIDs UID=1.3.12.2.1107.5.2.33.37113.30000008060311320917100000013/>
</ParticipantObjectContainsStudy>
</ParticipantObjectDescription>
</ParticipantObjectIdentification>
<ParticipantObjectIdentification ParticipantObjectID=P5^^^ISSUER ParticipantObject-
TypeCode=1 ParticipantObjectTypeCodeRole=1>
<ParticipantObjectIDTypeCode csd-code=2 originalText=Patient Number
codeSystemName=RFC-3881/>
<ParticipantObjectName>TEST^Name</ParticipantObjectName>
</ParticipantObjectIdentification>
</AuditMessage>
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
Query
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
Security Alert
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
User Authentication
Trigger Events
<TODO>
Message Structure
<TODO>
Sample Message
<TODO>
Patient Record
Trigger Events
<TODO>
Message Structure
<TODO s. ftp://medical.nema.org/medical/dicom/final/cp1323_ft_clarify_audit-codes.pdf>
Sample Message
<TODO>
Procedure Record
Trigger Events
<TODO>
Message Structure
<TODO s. ftp://medical.nema.org/medical/dicom/final/cp1323_ft_clarify_audit-codes.pdf>
Sample Message
<TODO>
dcm4che DICOM Archive 5 supports the Audit Trail Message Transmission Profile - SYSLOG-TLS as specified in
DICOM Standard, Part 15, Annex A.6.
dcm4che DICOM Archive 5 supports the Audit Trail Message Transmission Profile - SYSLOG-UDP as specified in
DICOM Standard, Part 15, Annex A.7.
dcm4che DICOM Archive 5 checks that the Association requestor specifies the correct Called AE Title. Each AE can
be configured to accept Association Requests from only a limited list of Calling AE Titles. In addition the IP address
of the requestor can be checked. Each AE can be configured to accepted only a limited list of Move Destinations in
C-MOVE requests.
Each AE can be configured to associate a particular Access Control ID to received Studies - optionally also dependend
on the Sending AE Title or on any DICOM Attribute of the first received object of the Study. Each AE can also be
configured to hide Studies from access by Query/Retrieve services which associated Access Control ID does not match
with a list of Access Control IDs associated with that AE.
Each AE can be configured to hide objects rejected by IHE IOCM Rejection Notes from access by Query/Retrieve
services dependend on the Key Object Selection Document Title of the Rejection Note.
dcm4che DICOM Archive 5 can be configured to check the Receiving Application and Facility in received HL7 v2
messages. Each HL7 Application provided by dcm4che DICOM Archive 5 can be configured to accept HL7 v2
messages from only a limited list of Sending Application and Facility names.
RESTful services and the Web UI may be secured with OpenID Connect using Keycloak as Authentication Server.
A V
Abstract Syntax, 12 Value Representation (VR), 13
Application Context, 12
Application Entity (AE), 12
Application Entity Title (AET), 12
Association, 12
Attribute, 12
I
Information Object Definition (IOD), 12
J
Joint Photographic Experts Group (JPEG), 12
M
Media Application Profile, 12
Module, 12
N
Negotiation, 12
P
Presentation Context, 12
Protocol Data Unit (PDU), 12
S
Security Profile, 13
Service Class Provider (SCP), 13
Service Class User (SCU), 13
Service/Object Pair Class (SOP Class), 13
Service/Object Pair Instance (SOP Instance), 13
T
Tag, 13
Transfer Syntax, 13
U
Unique Identifier (UID), 13
125