Document Number: 2019.

064 00

MODALITY WORKLIST
SERVER
DICOM
Conformance
Statement

Grupo Medical Ecoray B.V Página 1 de 16 Versión: 1.1

Document Number: 2019.064 00

Table of Contents

1 Revision History 4
2 Audiences 4
3 Remarks 4
4 Definitions, Terms and Abbreviations 4
6 References 5
7 Introductions 5
7.1. Overview 6
8 Implementation Model 6
8.1 Application Data Flow Diagram 6
8.2 Functional Definition of AE 6
8.3 Application Data Flow 7
8.4 Functional Definition of AEs 7
8.4.1 Functional Definition of δMWL Modality Worklist Server 7
8.5 Sequencing of Real-world Activities 7
9. AE Specifications 7
9.1 δMWL Modality Worklist Server Application Entity Specification 7
9.1.1. SOP Classes 7
9.1.2. Association Establishment Policy 8
9.1.2.1. General 8
9.1.2.2. Number of Associations 8
9.1.2.3. Asynchronous Nature 8
9.1.2.4. Implementation Identifying Information 8
9.1.3. Association Initiation Policy 8
9.1.4. Association Acceptance Policy 9
9.1.4.1. Activity - External Peer AE requests MWL query 9
9.1.4.2. Description and Sequencing of Activities 9
9.1.4.3. Accepted Presentation Contexts 9
9.1.4.4. SOP Specific Conformance 10
9.1.4.5. Specific Conformance for Verification SOP Class 10
9.1.4.6. Specific Conformance for Modality Worklist SOP Class 10
9.1.4.6.1. Modality Worklist Server AE C-STORE Response 10
9.1.4.6.2. Modality Server AE Storage Service Communication Failure Reasons 11
9.1.5. Find Request 11
9.1.5.1 Real-world Activity Associated with Find Request 11
9.1.5.2 Accepted Presentation Contexts 11
9.1.5.2.1 SOP Specific Conformance to the Supported Find SOP Classes 12
10 Communication Profiles 13
10.1 Supported Communications Stacks 13
10.2 Physical Network Interfaces 13
10.2.1 TCP/IP Stack 13
10.2.2 Physical Network Interface 13
10.2.3 Physical Media Support 13
11 Media Interchange 13

Grupo Medical Ecoray B.V Página 2 de 16 Versión: 1.1

Document Number: 2019.064 00

12 Extensions / Specializations 14
13 Configurations 14
13.1 AE Title/Presentation Address Mapping 14
13.1.1 Local AE Titles 14
13.1.2 Remote AE Title 14
13.2 Parameters 14
14 Supports of Extended Character Sets 15
15 Security 15
15.1 Security Profiles 15
15.2 Association Level Security 15
15.3 Application Level Security 15
16 Appendix A. Implementation Statements of IHE Integration Profiles 16

Grupo Medical Ecoray B.V Página 3 de 16 Versión: 1.1

Document Number: 2019.064 00

1 Revision History

Revision History
Revision 0.1 Jun 2019 uc
Revision 0.2 May 2020 hm
Ad update of MWL section, update configuration section

2 Audiences

This document is intended for hospital staff, health system integrators, software designers or
implementers. It is assumed that the reader has a working understanding of DICOM.

3 Remarks

DICOM, by itself, does not guarantee interoperability. However, the Conformance Statement
facilitates a first-level validation for interoperability between different applications supporting
the same DICOM functionality.

This Conformance Statement is not intended to replace validation with other DICOM
equipment to ensure proper exchange of information intended.

The scope of this Conformance Statement is to facilitate communication with vendor’s medical
equipment. The Conformance Statement should be read and understood in conjunction with
the DICOM Standard [DICOM]. However, by itself it is not guaranteed to ensure the desired
interoperability and successful interconnectivity with existing DICOM systems.

The user should be aware of the following important issues:

 The comparison of different conformance statements is the first step towards

assessing interconnectivity between equipment’s.
 Test procedures should be defined to validate the desired level of connectivity.
 The DICOM standard will evolve to meet the user’s future requirements. Is actively
involved in developing the standard further and therefore reserves the right to make
changes to its products or to discontinue its delivery.

4 Definitions, Terms and Abbreviations

Definitions, terms and abbreviations used in this document are defined within the different
parts of the DICOM standard. Abbreviations and terms are as follows:

AE DICOM Application Entity

AET Application Entity Title

Grupo Medical Ecoray B.V Página 4 de 16 Versión: 1.1

Document Number: 2019.064 00

DICOM Digital Imaging and Communications in Medicine

DIMSE DICOM Message Service Element
GSDF Grayscale Standard Display Function
HIS Hospital Information System
RIS Radiology Information System
IHE Integrating the Healthcare Enterprise
IHE-TF Integrating the Healthcare Enterprise Technical Framework
IAN Instance Availability Notification
IOD Information Object Definition
ISO International Standard Organization
PDU DICOM Protocol Data Unit
LUT Look-up Table
MPPS Modality Performed Procedure Step
MWL Modality Worklist
P-LUT Presentation Look-up Table
Q/R Query Retrieve
SCP Service Class Provider
SCU Service Class User
SCN Study Content Notification
SOP DICOM Service-Object Pair
TCP/IP Transmission Control Protocol/Internet Protocol
TLS Transport Layer Security
UID Unique Identifier
VR Value Representation

6 References

[DICOM] Digital Imaging and Communications in Medicine (DICOM), NEMA PS 3.1- 3.16, 2008
[IHE-TF] Integrating the Healthcare Enterprise Technical Framework, HIMSS/RSNA, Revision
5.4, 2012

7 Introductions
δMWL is a DICOM Modality Worklist Server that accepts visit orders from a HIS or a RIS either
through ASCII import, HL7 messages or manual data entry, and exports this data to Modalities
that can act as DICOM Modality Worklist Clients.

Since it acts as a channel between the HIS/RIS and the Modalities, it is important to realize that
the modalities can only receive data that is exported by the information system. If the IS
(Information System) does not send a required field to δMWL Modality Worklist Server, the
conformance cannot be guaranteed. Contact our company for a list of information that has
been validated.

Grupo Medical Ecoray B.V Página 5 de 16 Versión: 1.1

Document Number: 2019.064 00

7.1. Overview
δMWL Modality Worklist Server is a system that provides services for safe Workflow
Management.
δMWL Modality Worklist Server supports the following IHE Integration Profiles:
 Patient Information Reconciliation.
 Scheduled Workflow.
 Basic Security.
δMWL Modality Worklist Server supports the following network services:

Table 7.1 Network Services

Networking SOP Classes User of Service (SCU) Provider of Service (SCP)
Workflow Management
Modality Worklist - FIND No Yes
Modality Performed Procedure Step Yes Yes
Instance Availability Notification Yes No
Basic Study Content Notification Yes No
Connectivity Verification
Verification Yes Yes

8 Implementation Model
8.1 Application Data Flow Diagram

δMWL Modality Worklist Server is located between the HIS/RIS and the Modalities in the
following manner:

The actual input of the HIS/RIS data is provided by a separate product called Intel NUC, but as
the availability of certain types of worklist data is dependent on Intel NUC and its interaction
with the information, some of the configuration descriptions in this document refer to Intel
NUC.

8.2 Functional Definition of AE

Grupo Medical Ecoray B.V Página 6 de 16 Versión: 1.1

Document Number: 2019.064 00

The HIS actively sends out order messages to the δMWL Modality Worklist Server. They are
kept there in a local database. When a modality desires to acquire images, it creates an
association with δMWL Modality Worklist Server and sends a C-FIND-RQ message with a
query. δMWL Modality Worklist Server performs the query and replies with a number of C-
FIND-RSP messages, to return the matches found in the database, if any.

8.3 Application Data Flow

The Application Entities detailed in the Application Data Flow Diagram are all Java Enterprise
Application and are designed to run in a J2EE compliant container (i.e. JBoss) on any Java
Virtual Machine 1.7 capable Operating System.

The Modality Worklist Server AE implements the Verification Service Class and the Basic
Worklist Management Service Class

8.4 Functional Definition of AEs

8.4.1 Functional Definition of δMWL Modality Worklist Server

Application Entity

The δMWL Modality Worklist Server Application Entity waits for another application to
connect at the presentation address configured for its Application Entity Title. When another
application connects, the Modality Worklist Server AE expects it to be a DICOM application.
The Modality Worklist Server AE will accept Associations with Presentation Contexts for SOP
Classes of the Verification and Modality Worklist Service Classes.

When a Modality Worklist Find request is received, Modality Worklist Server AE will query the
local database for a list of Scheduled Procedure Steps matching the query and will return a
pending C-Find response for each match.

Before patient and order information can be included in response to a Modality Worklist
query, Modality Worklist items must be created by.

8.5 Sequencing of Real-world Activities

Not applicable.

9. AE Specifications
9.1. δMWL Modality Worklist Server Application Entity Specification
9.1.1. SOP Classes
δMWL Modality Worklist Server Application Entity provides Standard Conformance to the
following SOP Classes:

Grupo Medical Ecoray B.V Página 7 de 16 Versión: 1.1

Document Number: 2019.064 00

Table 9.1 SOP Classes for δMWL Modality Worklist Server AE

SOP Class Name SOP Class UID SCU SCP
Verification SOP Class 1.2.840.10008.1.1 No Yes
Modality Worklist Information Model - FIND 1.2.840.10008.5.1.4.31 No Yes

9.1.2. Association Establishment Policy

9.1.2.1. General
δMWL Modality Worklist Server AE can both accept and propose Association Requests. The
Query/Retrieve Server AE will accept Association Requests for the Verification and
Query/Retrieve Services. It will propose Associations for Verification and Storage Services.

The DICOM standard application context name for DICOM 3.0 is always accepted and
proposed:

Table 9.2 DICOM application context name for δMWL Modality Worklist Server AE
Application Context Name 1.2.840.10008.3.1.1.1

9.1.2.2. Number of Associations

δMWL Modality Worklist Server can support multiple simultaneous Associations requested by
peer AEs. Default is 10. This value can be configured through the attribute "MaxClients" in the
Application Server configuration file (i.e. jboss-service.xml for JBoss application server).

Table 9.3 Number of Associations accepted for δMWL Modality Worklist Server AE
Maximum number of simultaneous 10 (Configurable)
Associations

9.1.2.3. Asynchronous Nature

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

Table 9.4 Asynchronous Nature as SCP for δMWL Modality Worklist Server AE
Maximum number of outstanding asynchronous 1 (Not Configurable)

9.3.2.4. Implementation Identifying Information

The implementation information for this Application Entity is:

Table 9.5 DICOM Implementation Class and Version for δMWL Modality Worklist Server AE
Implementation Class UID 1.2.40.0.13.1.1
Implementation Version Name deltamwl-1.1

9.1.3. Association Initiation Policy

The Modality Worklist Server AE does not initiate Associations.

Grupo Medical Ecoray B.V Página 8 de 16 Versión: 1.1

Document Number: 2019.064 00

9.1.4. Association Acceptance Policy

9.1.4.1. Activity - External Peer AE requests MWL query
9.1.4.2. Description and Sequencing of Activities
The Modality Worklist Server 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 from certain
Application Entities.

When Modality Worklist SCUs query the Modality Worklist Server AE the queries run against
the MWL items in the local database.

When an association has been established the Sequencing of Real-World Activities is as

described in Section 1.3.1.3, “Sequencing of Real-World Activities”.

The Modality Worklist Server 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 (see PS 3.8, Section 9.3.4).

Table 9.6 Association Rejection Reasons

Result Source Reason Description
2 - rejected provider 2 - local-limit The (configurable) maximum number of
transient exceeded simultaneous associations has been reached.
An association request with the same
parameters may succeed at a later time.
1 - rejected user 2 - application The Association request contained an
permanent context name unsupported Application Context Name. An
not supported association request with the same
parameters will NOT succeed at a later time.
1 - rejected user 3 – calling AE The Association request contained an
permanent title not unrecognized Calling AETitle. An association
recognized request with the same parameters will NOT
succeed at a later time unless configuration
changes are made.

9.1.4.3. Accepted Presentation Contexts

Table 9.7 Accepted Presentation Contexts for δMWL Server AE

Abstract Syntax Transfer Syntax Role Ext.
Name UID Name List UID List Neg.
Verification 1.2.840.10008.1.1 Implicit 1.2.840.10008.1.2 SCP None
SOP Class VR Little
Endian
Modality 1.2.840.10008.5.1.4.3 Implicit 1.2.840.10008.1.2 SCP None
Worklist VR Little
Information Endian
Mod-el – Explicit 1.2.840.10008.1.2.1
FIND VR Little
Endian

Grupo Medical Ecoray B.V Página 9 de 16 Versión: 1.1

Document Number: 2019.064 00

If the Called AET is not corresponding to the actual Modality Worklist Server AET, only the
Presentation Context for the Verification SOP Class will be accepted.

9.1.4.4. SOP Specific Conformance

9.1.4.5. Specific Conformance for Verification SOP Class

δMWL Server provides standard conformance to the DICOM Verification Service Class as a SCP.
The status code for the C-ECHO is described in the following table:

Table 9.8 C-Echo Response Status Handling Behavior

Service Status Further Meaning Error Code Behavior
Success Success 0000 The C-ECHO request is accepted

9.1.4.6. Specific Conformance for Modality Worklist SOP Class

Return attributes depend on the information provided by the connected HIS/RIS. 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 Modality Worklist Server
database.

Table 9.9 Modality Worklist C-FIND SCP Supported Elements

Attribute Name Tag VR Types of Matching
Specific Character Set 0008,0005 CS NONE

Attribute Name Tag VR Types of Matching

Scheduled station AE title 0040,0001 AE S
Scheduled Procedure Step Start Date 0040,0002 DA S,R
Scheduled Procedure Step Start Time 0040,0003 TM S,R
Scheduled Performing Physician's Name 0040,0006 PN S,*
Modality 0008,0060 CS S
Accession Number 0008,0050 SH S
Patient's Name 0010,0010 PN S,*
Patient's ID 0010,0020 LO S
All others NONE

Types of Matching:

The types of Matching supported by the C-FIND SCP. An "S" indicates the identifier attribute
uses Single Value Matching, an "R" indicates Range Matching, an "*" indicates wildcard
matching, a "U" indicates Universal Matching. "NONE" indicates that no matching is
supported, but that values for this Element are requested to be returned.

9.1.4.6.1. Modality Worklist Server AE C-STORE Response

Table 9.10 δMWL Modality Worklist Server C-STORE Response Status

Service Status Further Meaning Error Code Behavior
Success Matching is complete 0000 Success indication message is

Grupo Medical Ecoray B.V Página 10 de 16 Versión: 1.1

Document Number: 2019.064 00

output to the Service Log.

This is treated as a permanent
Failure. The appropriate Status
will be sent in the C-FIND
Error Processing Failure 0110
Response. Error indication
message is output to the
Service Log.
This status is returned if a
Cancel Request is received from
Matching terminated the SCU during the processing
Canceled FE00
due to cancel request of a Modality Worklist request.
A cancel indication message is
output to the Service Log.
This status is returned with
each matching response. A
Pending Matching is continuing FF00
pending indication message is
output to the Service Log.

9.1.4.6.2. Modality Server AE Storage Service Communication Failure Reasons

Table 2.11 δMWL Modality Server Service Communication Failure Behavior

Exception Behavior
Association aborted by the SCU or the network layers indicate Error message is output to
communication loss (i.e. low-level TCP/IP socket closure) the Service Log.

9.1.5. Find Request

9.1.5.1 Real-world Activity Associated with Find Request

δMWL Modality Worklist Server receives a Find request, commonly from an AE that acts as a
modality, where it is generated by a user or automatically, in order to update the list of
scheduled procedures.

9.1.5.2 Accepted Presentation Contexts

The following Presentation Context will be accepted by δMWL Modality Worklist Server when
receiving a Find request:

Table 9.11 δMWL Modality Server Service Presentation Context accepted

Abstract Transfer Rol Extended
Syntax Syntax e Negotiatio
n
Name UID Name UID
Worklist DICOM
Information 1.2.840.10008.5.1.4.31 Implicit VR 1.2.840.10008.1.2 SCP none
model – FIND Little Endian

Grupo Medical Ecoray B.V Página 11 de 16 Versión: 1.1

Document Number: 2019.064 00

9.1.5.2.1 SOP Specific Conformance to the Supported Find SOP Classes

The supported keys are those listed as required, on the condition that they are indeed
provided by the HIS/RIS.

A typical HL7 message that is accepted by Intel NUC has the form:

MSH|^~\&|XXXX||||YYYMMDDHHMMSS||ORM^O01|YYYMMDDHHMMSS |P|2.2|||AL|NE
PID|||PATIENT ID||PATIENT NAME||DATE OF BIRTH|GENDER
ORC|NW|ACCESSION NUMBER
OBR||ACCESSION NUMBER||PROCEDURE TYPE|||||||||REASON FOR
PROCEDURE|||REFERRING PHYSICIAN||SEQUENCE NUMBER|ROOM||||||||PROCEDURE
DATE/TIME

The configuration of δMWL on Intel NUC defines which of these fields are written to which
database record. Currently, the default fields are:

PATIENT NAME
PATIENT ID
DATE OF BIRTH
GENDER
ACCESSION NUMBER
PROCEDURE TYPE
REASON FOR PROCEDURE
REFERRING PHYSICIAN
SEQUENCE NUMBER
ROOM
PROCEDURE DATE
PROCEDURE TIME

Up to 10 fields can be added to the Intel NUC database to add extra fields. When a δMWL
Modality Worklist Server query is received, these database records are converted to Scheduled
Procedures. Each field has a default mapping:

Table 9.12 δMWL Modality Server mapping of Scheduled Procedures Tag

PATIENT NAME 0010,0010
PATIENT ID 0010,0020
DATE OF BIRTH 0010,0030
GENDER 0010,0040
ACCESSION NUMBER 0008,0050
PROCEDURE TYPE 0040,0007
REASON FOR PROCEDURE 0040,0100
REFERRING PHYSICIAN 0008,0090
SEQUENCE NUMBER 0020,0010
ROOM 0008,0060
PROCEDURE DATE 0040,0002
PROCEDURE TIME 0040,0003

Grupo Medical Ecoray B.V Página 12 de 16 Versión: 1.1

Document Number: 2019.064 00

On installation, the mapping can be redefined. For each DICOM group-element pair one can
specify the database field from which it is filled. The same database field can be placed in
multiple DICOM fields, to accommodate groups of different modalities that all expect the
comments in different places, or, for example, the users wish the procedure type to be sent as
the study description as well.

A translation table can be defined for each field. This allows for example the ROOM code to be
converted to the DICOM Modality that is found in the corresponding physical room, and to the
AE Title for that modality. For each field, a default value can be defined. Even if the field is not
in the database, this value can be added to each procedure.

In short, this allows the institution to export all HIS/RIS supplied data in a form that is
acceptable for the modalities. If the HIS/RIS does not supply data that is required by the
modality, there is an interoperability problem that cannot be solved by the type of middleware
that δMWL Modality Worklist Server represents.

The current information for which δMWL Modality Worklist Server has been validated always
contain one Procedure Step per Procedure.

10 Communication Profiles
10.1 Supported Communications Stacks

δMWL Modality Worklist Server provides DICOM V3.0 TCP/IP Network Communication.
DICOM Upper Layer over TCP/IP is supported

10.2 Physical Network Interfaces

10.2.1 TCP/IP Stack

δMWL Modality Worklist Server uses the TCP/IP stack as provided by the Linux operating
system.

δMWL Modality Worklist Server inherits their TCP/IP stack from the installed Java Runtime
Environment.

10.2.2 Physical Network Interface

δMWL Modality Worklist Server is indifferent to the physical medium over which TCP/IP
executes; it inherits this from the Java Runtime Environment.

10.2.3 Physical Media Support

Intel NUC can connect to any medium that supports TCP/IP or the PC-AT bus.

11 Media Interchange

δMWL Modality Worklist Server does not support Media Storage.

Grupo Medical Ecoray B.V Página 13 de 16 Versión: 1.1

Document Number: 2019.064 00

12 Extensions / Specializations

Privatizations None.

13 Configurations
13.1 AE Title/Presentation Address Mapping
13.1.1 Local AE Titles

The local AE Titles and TCP ports are configurable through web interface

Table 13.1 AE Title Configuration Table

Application Entity Default AE Title Default TCP/IP Port
δMWL Modality Worklist Server MWL_SCP 2350

13.1.2 Remote AE Title

Remote AE Titles, TCP/IP Addresses and ports can be configured through web interface.
In the default configuration, Association Requests with any Calling AET will be accepted.

13.2 Parameters

The following table shows the δMWL Modality Worklist Server configuration parameters
relevant to DICOM communication. Refer to the δMWL Modality Worklist Server Service
Manual for details on general configuration capabilities.

Table 13.2 Configuration Parameter Table

Parameter Configurable Default
(Yes/No) Value
General Parameters
Listening Port Yes 2351
Maximum number of simultaneous Associations Yes 10
Time-out waiting for A-ASSOCIATE RQ on open TCP/IP Yes 5s
connection (ARTIM timeout)
Time-out waiting on an open association for the next Yes no timeout
message (DIMSE timeout)
Time-out waiting for acceptance or rejection Response to No no timeout
an Association Open Request. (Application Level timeout)
Time-out waiting on an open association for the next Yes 500ms
message after sending A-RELEASE RSP or A-ABORT RQ
(Closing timeout)
Maximum PDU size the AE can receive Yes 16352
Maximum PDU size the AE can send No 65535
Pack Command and Data PDVs in one PDU Yes false
Support for the Basic TLS Secure Transport Connection Yes Off
Profile
Accepted TLS Ciphers Yes -

Grupo Medical Ecoray B.V Página 14 de 16 Versión: 1.1

Document Number: 2019.064 00

Modality Worklist Server AE

Accepted Called AETs Yes MWL_SCP
Accepted Calling AETs Yes any

14 Supports of Extended Character Sets

δMWL Modality Worklist Server supports a single extended character set to be defined. The
character supports ISO_IR 100 (ISO 8859-1 Latin 1) as an extended character set. It is assumed
that this is the character set in which the information delivers its data.

δMWL Modality Worklist Server is a registered trademark of Grupo Medical Ecoray BV.
Specifications are subject to change without any notice.

15 Security
15.1 Security Profiles

δMWL Modality Worklist Server supports secure DICOM communication in conformance with
the Basic TLS Secure Transport Connection Profile. At default configuration, the TLS option is
deactivated.

15.2 Association Level Security

δMWL Modality Worklist Server can be configured to accept Association Requests from only a
limited list of Calling AETitles.

In the default configuration, Association requests with any Calling AET and any Called AET will
be accepted. However, if the Called AET is not correspondent to any of the actual Storage
Server AETs, only acceptance of the Presentation Context for Verification SOP Class will be
returned in the Association Acceptance Response (A-ASSOCIATE AC).

15.3 Application Level Security

δMWL Modality Worklist Server web module can be configured to require user authentication
in order to access to the user interface functionalities.

Grupo Medical Ecoray B.V Página 15 de 16 Versión: 1.1

Document Number: 2019.064 00

16 Appendix A. Implementation Statements of IHE Integration Profiles

δMWL Modality Worklist Server has implemented the following DICOM service classes and
HL7 messages:

 DICOM Storage Commitment Push Model SOP Class SCP

 DICOM Study Root Query/Retrieve Information Model - FIND SCP
 DICOM Study Root Query/Retrieve Information Model - MOVE SCP
 HL7 ADT^A02 (Patient Transfer) message receive
 HL7 ADT^A03 (Patient Discharge) message receive
 HL7 ADT^A06 (Change an Outpatient to an Inpatient) message receive
 HL7 ADT^A07 (Change an Inpatient to an Outpatient) message receive
 HL7 ADT^A08 (Update Patient Information) message receive
 HL7 ADT^A40 (Merge Patient Internal ID) message receive
 HL7 ADT^A12 (Cancel Patient Transfer) message receive
 HL7 ADT^A13 (Cancel Patient Discharge) message receive
 HL7 ORM (Procedure Scheduled) message receive
 HL7 ORM (Procedure Updated) message receive

Grupo Medical Ecoray B.V Página 16 de 16 Versión: 1.1