BASIC WORKLISTMANAGEMENT SERVER
Version 2.0
DICOM Conformance Statement

2012/12/141

1.Implementation model
The server runs on top of Windows system to respond to the worklist requests. It runs as a process thataccepts association requests from external applications. The server creates a separated thread for eachassociation request. Therefore, each thread communicates only with the requesting application.

1.1

Data flow
Figure 1 illustrates the relation between the server and external applications.
The aforementioned service does not perform any other operations except responding to the requests
received via DICOM connection.

QuerySCUBASICWORKLISTMANAGEMENT

Query DBSERVER

Send reply

DICOM interface
Fig 1. Worklist server implementation model

1.2

Application Entity function definition
Once the server is launched, it is awaiting for the connections from other applications via certain TCP/IPports. When a DICOM association is requested from another application, the server confirms the request
by using the database and the logic.
1. The server looks up the control table in order to confirm whether the name of the requested
application contained in the association request has been defined.
2. The server looks up the control table in order to find the application defined in the association
request as the name of the requesting application. It confirms whether the name of the requesting
application matches the value stored in the control table.

12.AE Specification
The server can be called multiple times from a single equipment unit and operate by using one instance.
Moreover, every time the association request is received, the server generates a copy of itself. Calling theserver and creating its copy express the same application entity.

AE Worklist Specification

2.1

The server, as an SCP, provides the standard conformance with the following DICOM 3.0 SCP classes.

Table 2. The SOP classes that the server supports as an SCPSOP Class NameSOP Class UID

Confirmation SOP class

1.2.840.10008.5.1.4.1.1

Modality Worklist Information Model – FIND

1.2.840.10008.5.1.4.31

2.1.1

Association Establishment Policy

2.1.1.1

SummaryOn receiving a C-FIND request from another application entity, the server attempts to initiate theassociation.
The default maximum PDU size for communication with the server is 32 KB.

2.1.1.2

Number of associations

The number of simultaneous associations the server can accept is restricted by the kernel parameters of
the basic TCP/IP implementation. Also, although the server generates a thread pool according to thesettings at startup, the number of simultaneous associations substantially depends on the mentionedparameters.

2.1.1.3

Asynchronous nature

The server does not support asynchronous operation and does not perform asynchronous window
negotiation.

2.1.1.4

Implementation Identifying Information

The server provides the implementation class UID 1.2.392.200036.9142.10000302.

2.2

Real-World Activity – Requesting
The server accepts associations from the nodes attempting to perform worklist request.

2.2.1

Presentation Context Table
Table 5 illustrates the Presentation Contexts that the server can accept in response to the query2

operations.

Table 5. Acceptable Presentation Contexts for request classPresentation Contexts
Abstract syntax
Name

Transfer syntax

UID

Modality

1.2.840.10008.5.1.4.31

Name

UID

DICOM

1.2.840.10008.1.2

worklist

Implicit VR

Request/Little endian

Role

Extended
Negotiation

SCP

None

Acquisition
information

DICOM

model - FIND

Explicit VR

1.2.840.10008.1.2.1

Little endian
DICOM
Explicit VR1.2.840.10008.1.2.2

Big endian

2.2.2

SOP Specific Conformance for Query SOP class
The server supports the modules listed in Table 6 as follows. However, because the server does not
update the database, it depends on the updating application whether the reply to the request can bereceived.

Table 6. SOP Common
Description

Tag

Specific Character Set

0008 0005

TypeO

Table 6. Scheduled Procedure Step
Description

Tag

Type

Scheduled Procedure Sequence

0040 0100

R>Schedule AE Title

0040 0001

R>Scheduled Date

0040 0002

R>Scheduled Time0040 0003

R>Modality

0008 0060

R>Scheduled Physician’s Name

0040 0006

R>Scheduled End Time0040 0005

O>Scheduled Station Name

0040 0010

O>Scheduled Location Code0040 0011

O>Scheduled Protocol Code Sequence

0040 0008

O>>Code Value

0008 0100

O>>Coding Scheme Designator

0008 0102

O>>Code Meaning

0008 0104

O>>Pre-Medication

0040 0012

O3

>Scheduled Number

0040 0009

O>Requested Contrast Agent

0032 1070

O

Table 6. Requested Procedure
Description

Tag

TypeRequested Procedure ID

0040 1001

ORequested Procedure Description

0032 1060

ORequested Procedure Code Sequence0032 1064O>Code Value

0008 0100

O>Coding Scheme Designator

0008 0102

O>Code Meaning

0008 0104

OStudy Instance UID

0020 000DO

Referenced Study Sequence

0008 1110

O>Referenced SOP Class UID

0008 1150

O>Referenced SOP Instance UID

0008 1155

O

Requested Procedure Priority

0040 1003

O

Patient Transport Mode

0040 1004

O

Table 6. Imaging Service Request
Description

Tag

TypeAccession Number

0008 0050

O

Requesting Physician

0032 1032

O

Referring Physician Name

0008 0090

O

Table 6. Visit Identification
Description

Tag

Admission ID

0038 0010

TypeO

Table 6. Visit Status
Description

Tag

Patient Location

0038 0300

TypeO

Table 6. Visit Relationship
Description

Tag

Type

Referenced Patient Sequence

0008 1120

O>Referenced SOP Class UID

0008 1150

O> Referenced SOP Instance UID

0008 1155

O

Table 6. Patient Identification
Description

Tag
4Type

Patient’s Name

0010 0010

R

Patient ID

0010 0020

R

Table 6. Patient Demographic
Description

Tag

Type

Patient’s Birth Date

0010 0030

O

Patient’s Sex

0010 0040

O

Patient’s Size

0010 1020

O

Patient’s Weight

0010 1030

O

Patient Data Confidentiality

0040 3001

O

Table 6. Patient Medical
Description

Tag

Type

Patient State

0038 0500

OPregnancy Status0010 21C0O

Medical Alerts

0010 2000

OAllergies

0010 2110

OSpecial Needs

0038 0050

O

Table 6.
Description

Tag

Institution Name

2.2.3

0008 0080

TypeO

Presentation Context Acceptance Criterion
Whether the server receives association requests from unknown applications depends on the systemsettings. Only if such requests are allowed, any number of the request SOP classes specified in Table 5
can be accepted. The server does not define a limit for the number of the accepted presentation
contexts. Also, among several duplicated presentation contexts, the first accepted one is to be selected.

2.2.4

Transfer Syntax Selection Policy
By default, the server selects transfer syntax according to the priority determined in Table 5; however thispriority can be changed in the system settings.

2.3

Real-World Activity – ConfirmingThis server accepts the associations from the nodes attempting to perform confirmation on the image
server.

2.3.1

Related Real-World Activity – Confirming
The real-world activity related to C-ECHO requests attempts to confirm the network and server
operations without initiating actual operation of external nodes.

52.3.2Presentation Context Table
Table 8 illustrates the Presentation Contexts the server can accept in response to the confirming
operation.

Table 8. Proposed Presentation Contexts of the Server for Confirming Operation
Presentation Contexts
Abstract Syntax
Name

Transfer Syntax

UID

Confirm 1.2.840.10008.1.1

Name

Role

Negotiation

UID

DICOM

1.2.840.10008.1.2

Extension

SCP

None

Implicit
VRLittle endian
DICOM
Explicit VR

1.2.840.10008.1.2.1

Little endian
DICOM
Explicit VR
Big endian
1.2.840.10008.1.2.2

2.3.3

Presentation Context Acceptance Criterion
Whether the server receives association requests from unknown applications depends on the systemsettings. Only if such requests are allowed, any number of the request SOP classes specified in Table 8
can be accepted. The server does not define a limit for the number of the accepted presentation
contexts. Also, among several duplicated presentation contexts, the first accepted one is to be selected.

2.3.4

Transfer Syntax Selection Criterion
By default, the server selects transfer syntax according to the priority determined in Table 5; however thispriority can be changed in the system settings.

6

3.Communication Profile
3.1

TCP/IP Stack
The server provides support for the DICOM V3.0 TCP/IP network communication defined in the part 8 of
the DICOM standard.

3.1.1

TCP/IP API
The server is using the TCP/IP stack from Windows system that is running the image server. The
subroutine library based on Berkeley sockets interface has been used.

3.1.2

Physical media support
The server exists as a software that can be compiled on various Windows platforms. Therefore, there isno limitation of the physical network. The image server is implemented by using TCP/IP over Ethernet(Thick Wire, Thin Wire, 10 Base T), FDDI (twisted pair into a concentrator, fiber backbone), Tin-CanTelephone-Net.

7

4.Extension / Specialization / Privatization
Not applicable

85.Configuration
The server obtains the configuration information from the “control” database stored in the related
database. In this implementation, the related database is an ini file.

AE Title / Presentation Address Mapping

5.1“Application Entity” in the control table is used for mapping between AE titles and presentation address.

Configurable parameters

5.2

The following parameters can be configured on the image server.

5.3-

Application entity title-

Maximum PDU size-Number of TCP/IP ports

Support of extended character sets
The server supports [ISO 2022 IR 13] and [ISO 2022 IR 87].

9