unosm dicom conformance statement - cuattro

UnoSM™ DICOM Conformance Statement


© 2009 Cuattro, LLC. All rights reserved. This document and the specifications may be changed at any

time, without notice. UnoSM™ is a registered trademark of Cuattro, LLC.



1. Conformance Statement Overview The conformance statement specifies the UnoSM™ conformance to DICOM v3.0.

UnoSM™ implements the necessary DICOM services to:

• download Modality Work Lists from an information system

• save acquired DX images and associated Presentation States to local drive, external USB drive,

or CD-R/DVD-R

• Store the acquired images to a DICOM server

UnoSM™ is not intended, nor appropriate for use in human medical applications. As demonstrated by

conformance to WG25 Veterinary and other specific designs, SM is intended for use only in veterinary

medical applications.

Table 1.1 provides an overview of the network services supported by UnoSM™.

Table 1.1 – Network Services

SOP Classes User of Service (SCU) Provider of Service (SCP)

Transfer

Verification YES NO

DX Image Storage YES NO

Workflow Management

Modality Worklist YES NO

Table 1.2 provides an overview of the Media Storage Application Profiles supported by UnoSM™.

Table 1.2 - Media Services

Media Storage Application

Profile

Write Files (FSC or FSU) Read Files (FSR)

Compact Disk - Recordable

General Purpose CD-R/DVD-R YES NO


2. Table of Contents 1. Conformance Statement Overview ...................................................................................................... 2

Table 1.1 – Network Services .................................................................................................................... 2

Table 1.2 - Media Services ........................................................................................................................ 2

3. Introduction .......................................................................................................................................... 6

3.1. Revision History ............................................................................................................................ 6

4. Networking ............................................................................................................................................ 7

4.1. Implementation Model ................................................................................................................. 7

4.1.1. Application Data Flow ........................................................................................................... 7

Figure 4.1-1 – Application Data Flow Diagram ..................................................................................... 7

4.1.2. Functional Definition of AEs .................................................................................................. 8

Figure 4.1.2 – Sequencing Constraints .................................................................................................. 9

4.2. AE Specifications ......................................................................................................................... 10

4.2.1. Storage Application Entity Specifications ........................................................................... 10

Table 4.2-1 SOP Classes for AE Storage .............................................................................................. 10

Table 4.2-2 DICOM Application Context for AE Storage ..................................................................... 10

Table 4.2-3 Number of Associations Initiated for AE Storage............................................................. 10

Table 4.2-4 Asynchronous Nature as a SCU for AE Storage ................................................................ 11

Table 4.2-5 DICOM Implementation Class and Version for AE Storage .............................................. 11

Figure 4.2-1 Sequencing of Activity – Send Images ............................................................................ 12

Table 4.2-7 – Proposed Presentation Contexts for Activity Send Images ........................................... 13

Table 4.2-8 Storage C-Store Response Status Handling Behavior ...................................................... 13

Table 4.2-9 Storage Communication Failure Behavior ....................................................................... 14

4.2.2. Workflow Application Entity Specifications ........................................................................ 14

Table 4.2-10 SOP Classes for AE Workflow ......................................................................................... 14

Table 4.2-11 DICOM Application Context for AE Workflow ............................................................... 15

Table 4.2-12 Number of Associations Initiated for AE Workflow ....................................................... 15

Table 4.2-13 Asynchronous Nature as a SCU for AE Workflow .......................................................... 15


Table 4.2-14 DICOM Implementation Class and Version for AE Workflow ........................................ 15

Figure 4.2-1 Sequencing of Activity – Worklist Update ...................................................................... 16

Table 4.2-15 – Proposed Presentation Contexts for Activity Worklist Update .................................. 17

Table 4.2-16 Storage C-Store Response Status Handling Behavior .................................................... 17

Table 4.2-17 Modality Worklist Communication Failure Behavior ..................................................... 19

Table 4.2-18 Worklist Request Identifier ............................................................................................ 19

4.2.3. Scheduled Protocol Codes and Procedure Mapping .......................................................... 21

4.3. Network Interfaces ..................................................................................................................... 23

4.3.1. Physical Network Interface ................................................................................................. 23

Table 4.3-1 Supported Physical Network Interfaces ........................................................................... 23

4.3.2. Additional Protocols ............................................................................................................ 23

Table 4.3-2 - Supported System Management Profiles ...................................................................... 23

Table 4.3-3 Supported DHCP Parameters ........................................................................................... 24

4.3.3. IPv4 and IPv6 Support ......................................................................................................... 24

4.4. Configuration .............................................................................................................................. 25

4.4.1. AE Title/Presentation Address Mapping ............................................................................. 25

Table 4.4-1 - AE Title Configuration Table .......................................................................................... 25

4.4.2. Parameters .......................................................................................................................... 25

Table 4.4-10 - Configuration Parameters Table .................................................................................. 26

5. Media Interchange .............................................................................................................................. 27

5.1. Implementation Model ............................................................................................................... 27

5.1.1. Application Data Flow ......................................................................................................... 27

Figure 5.1-1 - Application Data Flow Diagram for Media Storage ...................................................... 27

5.1.2. Functional Definition of AEs ................................................................................................ 27

5.1.3. Sequencing of Real-World Activities ................................................................................... 27

5.1.4 File Meta Information Options ........................................................................................... 28

Table 5.1-1 - DICOM Implementation Class and Version for Media Storage ..................................... 28

5.2. AE SPECIFICATIONS ..................................................................................................................... 28

5.2.1. Offline-Media Application Entity Specification ................................................................... 28

Table 5.2-1 - Application Profiles, Activities and Roles for Offline-Media .......................................... 28

Table 5.2-2 - IODs, SOP Classes and Transfer Syntaxes for OfflineMedia .......................................... 29


5.3 Augmented and Private Application Profiles .............................................................................. 29

5.4 Media Configuration ................................................................................................................... 29

Table 5.4-1 - AE Title Configuration Table .......................................................................................... 29

6. Support of Character Sets ................................................................................................................... 30

7. Security ............................................................................................................................................... 31

8. Annexes ............................................................................................................................................... 31

8.1.1 Created SOP Instances ........................................................................................................ 31

Table 8.1-1 - IOD of created DX SOP Instances ................................................................................... 32

Table 8.1-2 - Patient Module of created SOP Instances ..................................................................... 33

Table 8.1-3 - General Study Module of created SOP Instances .......................................................... 33

Table 8.1-4 - Patient Study Module of created SOP Instances ........................................................... 34

Table 8.1-5 - General Series Module of created SOP Instances.......................................................... 34

Table 8.1-6 - General Equipment Module of created SOP Instances ................................................. 34

Table 8.1-7 - General Image Module of created DX SOP Instances .................................................... 35

Table 8.1-8 - Image Pixel Module of created DX SOP Instances ......................................................... 35

Table 8.1-9 - Display Shutter Module of created DX SOP Instances ................................................... 36

Table 8.1-10 - DX ANATOMY IMAGED OF CREATED DX SOP INSTANCES ........................................... 36

Table 8.1-11 - DX IMAGE OF CREATED DX SOP INSTANCES ................................................................ 36

Table 8.1-12 - DX DETECTOR created DX SOP Instances ..................................................................... 37

Table 8.1-13 - DX POSITIONING CREATED DX SOP INSTANCES........................................................... 37

Table 8.1-14 - X-Ray Acquisition Dose CREATED DX SOP INSTANCES ................................................. 37

Table 8.1-15 - SOP Common Module of created DX SOP Instances ................................................... 38

8.1.2. Used Fields in received IOD by application ......................................................................... 38

8.1.3. Attribute mapping ............................................................................................................... 38

Table 8.1-16 - Attribute Mapping Between Modality Worklist AND Image ....................................... 38

8.1.4. Coerced/Modified Fields ..................................................................................................... 39

8.2. Data Dictionary of Private Attributes .......................................................................................... 39

Table 8.2-1 - Data Dictionary of Private Attributes ............................................................................. 39

8.3. Coded Terminology and Templates ............................................................................................ 39

8.4. Grayscale Image Consistency ...................................................................................................... 40

8.5. Standard Extended / Specialized / Private SOP Classes .............................................................. 40


8.6. Private Transfer Syntaxes ............................................................................................................ 40

3. Introduction

3.1. Revision History

Date Version Contributor Description

8/25/09 0.1 D. Blanchard Initial specification

10/1/09 0.3 / 0.4 D. Blanchard Added Scheduled Protocol Codes and Procedure Mapping

section for more info on how Procedures are made from

MWL response


4. Networking

4.1. Implementation Model

4.1.1. Application Data Flow

Figure 4.1-1 – Application Data Flow Diagram

Send

Images

Storage

Application

Entity

Remote

Application

Entity Receives

Images

Update

Worklist

Workflow

Application

Entity

Remote

Application

Entity Provides

Worklist Items

DICOM Standard Interface

-- The Storage Application Entity sends images to a remote AE. It is associated with the local real-world

activity “Send Images”. “Send Images” is performed upon user request for each study completed.

“Send Images” can also be performed for an in-progress study to a View Station. When activated by

user’s settings (“Default DICOM Server”), when ending a study, all non-rejected images can be

immediately stored to a preferred destination.

-- The Workflow Application Entity receives Worklist information from a remote AE. It is associated with

the real-world activity “Update Worklist”. When the “Update Worklist” local real-world activity is

performed, the Workflow Application Entity queries a remote AE for Worklist items and provides the set

of Worklist items matching the query request. ”Update Worklist” is performed as a result of an operator

request or can be performed automatically at specific time intervals.


4.1.2. Functional Definition of AEs

4.1.2.1. Functional Definition of Storage Application Entity

The existence of a send-job queue entry with associated network destination will activate the Storage

AE. An association request is sent to the destination AE and upon successful negotiation of a

Presentation Context the image transfer is started. If the association cannot be opened, the related

send-job is paused for a default of 10 seconds1, and attempted again (up to 10 attempts

1). If after the

10 attempts the store is not successful, it is set to an error state and can be restarted by the user via the

DICOM Spooler screen.

1 These values are configurable by a service technician.

4.1.2.2. Functional Definition of Workflow Application Entity

“Worklist Update” local real world activity attempts to download a Worklist from a remote server. If the

Workflow AE establishes an Association to a remote AE, it will transfer all Worklist items matching

specified search criteria2 via the open Association. During receiving the Worklist response items will be

displayed in a separate list, which will be cleared with the next Worklist Update.

Auto-refresh of pending studies will occur if configured to do so. The interval in which the auto-refresh

occurs is configurable as well.


4.1.2.3. Sequencing of Real-World Activities

Figure 4.1.2 – Sequencing Constraints

Storage Workflow Modality Worklist Server PACS / Storage Server

1. Query Worklist

2. Receive Worklist

3. Select Workitem

4. Acquire Images

5. Complete Acquisition

6. Store Acquired Images

Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure 4.1-2

apply:

1. Query Worklist

2. Receive Worklist of Modality Scheduled Procedure Steps (MSPS)

3. Select Work item (MSPS) from Worklist

4. Start acquisition

5. Acquire Images

6. Complete acquisition

7. Store acquired images Other workflow situations (e.g. unscheduled procedure steps) will have other sequencing constraints.


4.2. AE Specifications

4.2.1. Storage Application Entity Specifications

4.2.1.1. SOP Classes

UnoSM™ provides Standard Conformance to the following SOP Classes:

Table 4.2-1 SOP Classes for AE Storage

SOP Class Name SOP Class UID SCU SCP

Digital X-Ray Image Storage – For

Presentation

1.2.840.10008.5.1.4.1.1.1.1 YES NO

Verification 1.2.840.10008.1.1 YES NO

4.2.1.2. Association Policies

4.2.1.2.1. General

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

Table 4.2-2 DICOM Application Context for AE Storage

Application Context Name 1.2.840.10008.3.1.1.1

4.2.1.2.2. Number of Associations

By default, UnoSM™ initiates up to three Associations2 at a time for each destination to which a transfer

request is being processed in the active job queue list. By default, up to 3 jobs2 will be active at a time,

the other remains pending until the active job is completed or failed.

2 These settings are configurable by a service technician.

Table 4.2-3 Number of Associations Initiated for AE Storage

Maximum number of simultaneous Association 3 (configurable)

4.2.1.2.3. Asynchronous Nature

UnoSM™ does support asynchronous communication (multiple outstanding transactions over a single

Association).


Table 4.2-4 Asynchronous Nature as a SCU for AE Storage

Maximum number of outstanding asynchronous Transactions

3 (configurable)

4.2.1.2.4. Implementation Identifying Information

The implementation information for this Application Entity is:

Table 4.2-5 DICOM Implementation Class and Version for AE Storage

Implementation Class UID 2.16.840.1.114440.1.4

Implementation Version Name UNOSM

4.2.1.3. Association Initiation Policy

4.2.1.3.1. Activity – Send Images

4.2.1.3.1.1. Description and Sequencing of Activities

A user can select images and request them to be sent to multiple destinations (up to 2). Each request is

forwarded to the job queue and processed individually. When the “Default DICOM Server” option is

active, when a study is ended, each marked instance or marked set of instances stored in database will

be forwarded to the network job queue for a pre-configured UnoSM™ target destination. It can be

configured the destination where the instances are automatically sent to. The “UnoSM™” is triggered by

the End Study user application.

The Storage AE is invoked by the job control interface that is responsible for processing network archival

tasks. The job consists of data describing the instances marked for storage and the destination. An

internal daemon process triggered by a job for a specific network destination initiates a C-STORE request

to store images. If the process successfully establishes an Association to a remote Application Entity, it

will transfer each marked instance simultaneously3 via the open Association. Status of the transfer is

reported through the job control interface. Up to three jobs3 will be active at a time. If the C-STORE

response from the remote Application contains a status other than Success or Warning, the Association

is aborted and the related store is switched to an “In Progress – Re-attempting” state. It will

automatically re-attempt 10 times by default4. If the job is not successful after 10 attempts, the store

will be switched to a failed state. It can be restarted any time by user interaction in the DICOM Spooler

screen

The Storage AE attempts to initiate a new Association in order to issue a C-STORE request. If the job

contains multiple images then multiple C-STORE requests will be issued over the same Association.

3 Default is up to 3 simultaneous storage sends. This can be configured by a service technician.


4 Default is up to 10 re-attempts, with a default delay of 10 seconds between attempts. This can be configured by a

service technician.

Figure 4.2-1 Sequencing of Activity – Send Images

Storage AE PACS / Storage Server

1. Open Association

2. C-STORE (DX Image)

3. C-STORE (DX Image)

4. Close Association

A possible sequence of interactions between the Storage AE and a PACS / DICOM Storage Server (e.g. a

storage or archive device supporting the Storage and Storage Commitment SOP Classes as an SCP) is

illustrated in Figure 4.2-1:

1. The Storage AE opens an association with the PACS / DICOM Storage Server

2. An acquired DX image is transmitted to the PACS / DICOM Storage Server using a C-STORE request

and the Image Manager replies with a C-STORE response (status success).

3. Another acquired DX image is transmitted to the Image Manager using a C-STORE request and the

Image Manager replies with a C-STORE response (status success).

4. The Storage AE closes the association with the PACS / DICOM Storage Server.

NOTE: Other message sequences are possible depending on the number of images to be stored.

4.2.1.3.1.2. Proposed Presentation Contexts

UnoSM™ is capable of proposing the Presentation Contexts shown in the following table:


Table 4.2-7 – Proposed Presentation Contexts for Activity Send Images

Presentation Context Table

Abstract Syntax Transfer Syntax

Role

Ext.

Neg. Name UID Name List UID List

X-Ray Image

Storage – For

Presentation

1.2.840.10008.5.1.

4.1.1.1.1

Implicit VR Little

Endian

Explicit VR Little

Endian

1.2.840.10008.1.2

1.2.840.10008.1.2.1

SCU

NONE

Table 4.2-8 Storage C-Store Response Status Handling Behavior

Service Status Further Meaning Error Code Behavior

Success Success 0000 The SCP has successfully stored the SOP

Instance. If all SOP Instances in a send job

have status success then the job is marked as

complete.

Refused Out of Resources

A700-A7FF The Association is aborted using A-ABORT and

the send job is marked as failed. The status

meaning is logged and the job failure is

reported to the user via the job control

application. This is a transient failure.

Error

Data Set does not match SOP Class

A900-A9FF The Association is aborted using A-ABORT and




application.

Error

Cannot Understand

C000-CFFF The Association is aborted using A-ABORT and




application.

Warning

Coercion of Data Elements

B000 Image transmission is considered successful

but the status meaning is logged.

Warning

Data Set does not match SOP Class



Warning

Elements Discarded




* * Any other status code.

The Association is aborted using A-ABORT and


code is logged and the job failure is reported

to the user via the job control

application.

The behavior of Storage AE during communication failure is summarized in the Table below:

Table 4.2-9 Storage Communication Failure Behavior

Exception Behavior

Timeout

The Association is aborted using A-ABORT and the send job is marked as failed. The reason is logged and the job failure is reported to the user via the job control application.

Association aborted by the SCP or network layers The send job is marked as failed. The reason is logged and the job failure is reported to the user via the job control application.

A failed send job can be restarted by user interaction. The system can be configured to automatically

resend failed jobs if a transient status code is received. The delay between resending failed jobs and the

number of retries is also configurable.

The contents of Digital X-Ray Image Storage SOP Instances created by UnoSM conform to the DICOM

Digital X-Ray Image IOD definition and are described in section 8.1.

4.2.2. Workflow Application Entity Specifications

4.2.2.1. SOP Classes

UnoSM™ provides Standard Conformance to the following SOP Classes:

Table 4.2-10 SOP Classes for AE Workflow

SOP Class Name SOP Class UID SCU SCP

Modality Worklist Information

Model – FIND

1.2.840.10008.5.1.4.31 YES NO

4.2.2.2. Association Policies

4.2.2.2.1. General

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


Table 4.2-11 DICOM Application Context for AE Workflow

Application Context Name 1.2.840.10008.3.1.1.1

4.2.2.2.2. Number of Associations

UnoSM™ initiates one Association at a time for a Worklist request.

Table 4.2-12 Number of Associations Initiated for AE Workflow

Maximum number of simultaneous Association 1

4.2.2.2.3. Asynchronous Nature

UnoSM™ does not support asynchronous communication (multiple outstanding transactions over a single

Association).

Table 4.2-13 Asynchronous Nature as a SCU for AE Workflow

Maximum number of outstanding asynchronous Transactions

1

4.2.2.2.4. Implementation Identifying Information

The implementation information for this Application Entity is:

Table 4.2-14 DICOM Implementation Class and Version for AE Workflow



4.2.2.3. Association Initiation Policy

4.2.2.3.1. Activity – Send Images

4.2.2.3.1.1. Description and Sequencing of Activities

The request for a Worklist Update is initiated immediately on the Pending Studies List screen, or

automatically at specific time intervals, or by user interaction, i.e. pressing the refresh button on the

Pending Studies List screen. With “Worklist Update” the automated query mechanism is performed


immediately on request. Default search settings for the Work list queries are specified in the Modality

Worklist settings screen.

With automated worklist queries (including “Worklist Update”) the UNOSM™ always requests all items

for a Scheduled Procedure Step Start Date (actual date), Modality (DX) and Scheduled Station AE Title.

Query for the Scheduled Station AE Title is configurable by a Service technician in the Modality Worklist

Setting screen.

Upon initiation of the request, the UNOSM™ will build an Identifier for the CFIND request, will initiate an

Association to send the request and will wait for Worklist responses. After retrieval of all responses,

UNOSM™ will access the local database to add or update patient demographic data. To protect the

system from overflow, the UNOSM™ will limit the number of processed Worklist responses to a

configurable maximum. The results will be displayed in a separate list, which will be cleared with the

next Worklist update.

UNOSM™ will initiate an Association in order to issue a C-FIND request according to the Modality

Worklist Information Model.

Figure 4.2-1 Sequencing of Activity – Worklist Update

A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g. a

device such as a RIS or HIS which 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

attributes.

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 indicating 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.

Table 4.2-15 – Proposed Presentation Contexts for Activity Worklist Update

Presentation Context Table

Abstract Syntax Transfer Syntax

Role

Ext.

Neg. Name UID Name List UID List

Modality Worklist

Information Model

– FIND

1.2.840.10008.5.1.

4.31

Implicit VR Little

Endian

Explicit VR Little Endian

1.2.840.10008.1.2

1.2.840.10008.1.2.1

SCU

NONE

4.2.2.3.1.2. SOP Specific Conformance for Modality Worklist

The behavior of UnoSM™ when encountering status codes in a Modality Worklist C-FIND response is

summarized in the Table below. If any other SCP response status than "Success" or "Pending" is

received by UNOSM™, a message “MODALITY WORKLIST SERVER UNAVAILABLE” will appear on the user

interface.

Table 4.2-16 Storage C-Store Response Status Handling Behavior

Service Status Further Meaning Error Code Behavior


Success Matching is

complete 0000 The SCP has completed the matches. Worklist

items are available for display or further

processing.

Refused Out of Resources

A700-A7FF The query is marked as failed. The status

meaning is logged and reported to the user if

an interactive query. Any additional error

information in the Response will be logged.

Failed

Identifier does not match SOP Class

A900 The Association is aborted using A-ABORT and

the worklist query is marked as failed. The

status meaning is logged and reported to the

user if an interactive query. Any additional

error information in the Response will be

logged.

Failed Unable to Process

C000-CFFF The Association is aborted using A-ABORT and

the worklist query is marked as failed. The

status meaning is logged and reported to the

user if an interactive query. Any additional

error information in the Response will be

logged.

Cancel

Matching terminated due to Cancel request

FE00 If the query was cancelled due to too many

worklist items then the SCP has completed

the matches. Worklist items are available for

display or further processing. Otherwise, the

Association is aborted using A-ABORT and the

worklist query is marked as failed. The status


an interactive query.

Pending

Matches are continuing

FF00 The worklist item contained in the Identifier is

collected for later display or further

processing.

Pending

Matches are continuing – Warning that one or more Optional Keys were not supported

FF01 The worklist item contained in the Identifier is

collected for later display or further

processing. The status meaning is logged only

once for each C-FIND operation.

* * Any other status code.

The Association is aborted using A-ABORT and

the worklist is marked as failed. The status


an interactive query. Any additional error

information in the Response will be logged.


Table 4.2-17 Modality Worklist Communication Failure Behavior

Exception Behavior

Timeout

The Association is aborted using A-ABORT and the

worklist query marked as failed. The reason is logged

and reported to the user if an interactive

query.

Association aborted by the SCP or network layers The worklist query is marked as failed. The reason is

logged and the job failure is reported to the user via the

job control application.

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 UNOSM™ 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.

Table 4.2-18 Worklist Request Identifier


Module Name

Attribute Name

Tag VR M R Q D IOD

SOP Common

Specific Character Set

(0008, 0005) CS x

Scheduled Procedure Step

Scheduled Procedure Step Sequence

> Scheduled Station AET

> Scheduled Procedure Step Start Date

> Scheduled Procedure Step Start Time

> Modality

> Scheduled Performing Physician’s Name

> Scheduled Procedure Step Description

> Scheduled Station Name

> Scheduled Procedure Step Location

> Scheduled Protocol Code Sequence

> Pre-Medication

> Scheduled Procedure Step ID

> Requested Contrast Agent

(0040,0100)

(0040,0001)

(0040,0002)

(0040,0003)

(0008,0060)

(0040,0006)

(0040,0007)

(0040,0010)

(0040,0011)

(0040,0008)

(0040,0012)

(0040,0009)

(0032,1070)

SQ

AE

DA

TM

CS

PN

LO

SH

SH

SQ

LO

SH

LO

(S)

S

S

x x x x x x x x x x x X

x

x

x

x

x

x

x

x

x

x

x

x

x

Requested Procedure

Requested Procedure ID

Requested Procedure Description

Study Instance UID

Requested Procedure Priority

Patient Transport Arrangements

Referenced Study Sequence

Requested Procedure Code Sequence

(0040,1001)

(0032,1060)

(0020,000D)

(0040,1003)

(0040,1004)

(0008,1110)

(0032,1064)

SH

LO

UI

SH

LO

SQ

SQ

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Imaging Service Request

Accession Number

Requesting Physician

Referring Physician's Name

(0008,0050)

(0032,1032)

(0008,0090)

SH

PN

PN

x

x

x

x

x

x

x

x

x

x

x

Visit Identification

Admission ID

(0038,0010)

LO

x

Visit Status

Current Patient Location

(0038,0300)

LO

x

x

Visit Admission

Admitting Diagnosis Description

(0008,1080)

LO

x

x

Patient Identification

Patient Name

Patient ID

(0010,0010)

(0010,0020)

PN

LO

x

x

x

x

x

x

x

x

Patient Demographic

Patient’s Birth Date

Patient’s Sex

Patient’s Weight

Confidentiality constraint on patient data

(0010,0030)

(0010,0040)

(0010,1030)

(0040,3001)

DA

CS

DS

LO

x

x

x

x

x

x

x

x

x

x

x

x

x

Patient Medical

Patient State

(0038,0500)

LO

x

x


Pregnancy Status

Medical Alerts

Allergies

Special Needs

(0010,21C0)

(0010,2000)

(0010,2110)

(0038,0050)

US

LO

LO

LO

x

x

x

x

x

x

x

x

The above table should be read as follows:

Module Name: The name of the associated module for supported worklist attributes.

Attribute Name: Attributes supported to build an UNOSM™ Worklist Request Identifier.

Tag: DICOM tag for this attribute.

VR: DICOM VR for this attribute.

M: Matching keys for (automatic) Worklist Update. An "S" will indicate that UnoSM will

supply an attribute value for Single Value Matching, an “R” will indicate Range Matching and a “*” will

denote wildcard matching. It can be configured if “Scheduled Station AE Title” is additionally supplied

“(S)” and if Modality is set to RF or SC.

R: Return keys. An "x" will indicate that UNOSM™ will supply this attribute as Return Key

with zero length for Universal Matching. The UNOSM™ will support retired date format (yyyy.mm.dd)

for "Patient’s Birth Date" and "Scheduled Procedure Step Start Date" in the response identifiers. For

"Scheduled Procedure Step Start Time" also retired time formats as well as unspecified time

components are supported.

Q: Interactive Query Key. An “x” “will indicate that UNOSM™ will supply this attribute as

matching key, if entered in the Query Patient Worklist dialog. For example, the Patient Name can be

entered thereby restricting Worklist responses to Procedure Steps scheduled for the patient.

D: Displayed keys. An “x” indicates that this worklist attribute is displayed to the user

during a patient registration dialog. For example, Patient Name will be displayed when registering the

patient prior to an examination.

IOD: An "x" indicates that this Worklist attribute is included into all Object Instances created

during performance of the related Procedure Step.

The default Query Configuration is set to "Modality" (DX) and "Date" (date of today). Optionally,

additional matching for the own AET is configurable.

4.2.3. Scheduled Protocol Codes and Procedure Mapping

4.2.3.1. Scheduled Procedure Step Description (0040,0007) and Scheduled Protocol

Code Sequence (0040,0008) are mapped to Procedures in Uno.


4.2.3.2. Procedures must be configured in the Uno application in the Acquisition ->

Procedures Setting screen.

4.2.3.2.1. A Procedure contains a Name and an optional DICOM Code.

4.2.3.2.2. A procedure contains one or more Anatomy View Pairs (AVPs), which

are configured in the Procedures Setting Screen. An anatomy view pair

specifies a shot to be taken.

4.2.3.3. When a MWL study is started, it creates Study Procedures for that study, and

creates Study Procedure AVPs for the procedure matches, as described below.

4.2.3.4. Scheduled Procedure Step Description (0040,0007) may contain a comma

separated list of Procedure Names.

4.2.3.4.1. Uno attempts to match each Procedure Name in this tag to Uno

Procedure Names (defined in the setting screen mentioned above).

4.2.3.4.2. If any procedure name is not found, it is displayed to the user when

attempting to start a MWL study.

4.2.3.5. Scheduled Protocol Code Sequence (0040,0008) may contain 0 or more Code

Sequence Macro sequence items.

4.2.3.5.1. Each Code Sequence Macro has the following tags (as per Table 8.8-1 in

Part 3 of the DICOM Standard):

4.2.3.5.1.1. Code Value (0008,0100) - this is typically a code value such as "C-1000"

4.2.3.5.1.2. Coding Scheme Designator (0008,0102)

4.2.3.5.1.3. Code Meaning (0008,0104) - this is typically a description or name such

as "Abdomen"

4.2.3.5.2. For each Code Sequence Macro item, Uno attempts to parse with the

following rules:

4.2.3.5.2.1. Checks if we have already found the Code Value (0008,0100) value in

another tag, if so, then does not add it as a Study Procedure. (This is to

prevent duplicates if both Scheduled Protocol Code Sequence

(0040,0008) and Scheduled Procedure Step Description (0040,0007) is

sent back in the response)

4.2.3.5.2.2. Attempts to find a match with the Code Value (0008,0100) value from

the MWL response with the DICOM Code value as configured in Uno



4.2.3.5.2.3. Attempts to find a match with the Code Value (0008,0100) value from

the MWL response with the Procedure Name value as configured in Uno


4.2.3.5.2.4. Attempts to find a match with the Code Meaning (0008,0104) value

from the MWL response with the DICOM Code value as configured in Uno


4.2.3.5.2.5. Attempts to find a match with the Code Meaning (0008,0104) value

from the MWL response with the Procedure Name value as configured in

Uno Procedures Setting screen.

4.2.3.5.3. Note: When a match is found by Code Value (0008,0100), the

application uses the Procedure Name associated with that Code Value

(0008,0100) value, *NOT* the Code Meaning (0008,0104) value in the MWL

response.

4.3. Network Interfaces

4.3.1. Physical Network Interface

UNOSM™ supports a single network interface. One of the following physical network interfaces will be

available depending on installed hardware options:

Table 4.3-1 Supported Physical Network Interfaces

Ethernet 100baseT

Ethernet 10baseT

4.3.2. Additional Protocols

UnoSM™ conforms to the System Management Profiles listed in the Table below. All requested

transactions for the listed profiles and actors are supported. Support for optional transactions is listed

in the Table below:

Table 4.3-2 - Supported System Management Profiles

Profile Name Actor Protocols Used Optional Transactions Security Support

Network Address Management

DHCP Client

DHCP N/A

DNS Client DNS N/A


4.3.2.1. DHCP

DHCP can be used to obtain TCP/IP network configuration information. The network parameters

obtainable via DHCP are shown in the Table below. The Default Value column of the table shows the

default used if the DHCP server does not provide a value. Values for network parameters set in the

Service/Installation tool take precedence over values obtained from the DHCP server. Support for DHCP

can be configured via the Service/Installation Tool. The Service/Installation tool can be used to

configure the machine name. If DHCP is not in use, TCP/IP network configuration information can be

manually configured via the Service/Installation Tool.

Table 4.3-3 Supported DHCP Parameters

DHCP Parameter Default Value

IP Address None

Hostname Requested machine name

List of NTP servers Empty list

List of DNS servers Empty list

Routers Empty list

Static routes None

Domain name None

Subnet mask Derived from IP Address (see service manual)

Broadcast address Derived from IP Address (see service manual)

Default router None

If the DHCP server refuses to renew a lease on the assigned IP address all active DICOM Associations will

be aborted.

4.3.2.2. DNS

DNS can be used for address resolution. If DHCP is not in use or the DHCP server does not return any

DNS server addresses, the identity of a DNS server can be configured via the Service/Installation Tool. If

a DNS server is not in use, local mapping between hostname and IP address can be manually configured

via the Service/Installation Tool.

4.3.3. IPv4 and IPv6 Support

This product only supports IPv4 connections.


4.4. Configuration

4.4.1. AE Title/Presentation Address Mapping

4.4.1.1. Local AE Titles

All local applications use the AE Titles and TCP/IP Ports configured via the Service/Installation Tool. The

Field Service Engineer can configure the TCP Port via the Service/Installation Tool. There is a default AE

Title are provided. The AE Titles must be configured during installation. The local AE Title used by each

individual application can be configured independently of the AE Title used by other local applications.

If so configured, all local AEs are capable of using the same AE Title.

Table 4.4-1 - AE Title Configuration Table

Application Entity Default AE Title Default TCP/IP Port

Storage UNOSM Not Applicable

Workflow UNOSM Not Applicable

4.4.1.2. Remote AE Title/Presentation Address Mapping

The AE Title, host names and port numbers of remote applications are configured using the UnoSM™

Service/Installation Tool.

4.4.1.2.1. Storage

The UnoSM™ Service/Installation Tool must be used to set the AE Titles, port-numbers, host-names and

capabilities for the remote Storage SCPs. Associations will only be accepted from known AE Titles and

associations from unknown AE Titles will be rejected (an AE Title is known if it can be selected within the

Service/Installation Tool). Multiple remote Storage SCPs can be defined. Any Storage SCP can be

configured to be an “Archive” device causing storage commitment to be requested for images or

presentation states transmitted to the device.

4.4.1.2.2. Workflow

The UnoSM™ Service/Installation Tool must be used to set the AE Title, port-number, host-name and

capabilities of the remote Modality Worklist SCP. More than one Modality Worklist SCP can be defined

but only one can be active at one time.

4.4.2. Parameters

A large number of parameters related to acquisition and general operation can be configured using the

Service/Installation Tool. The Table below only shows those configuration parameters relevant to

DICOM communication. See the UnoSM™ Service Manual for details on general configuration

capabilities.


Table 4.4-10 - Configuration Parameters Table

Parameter Configurable (Yes/No)

Default Value

General Parameters

Max PDU Receive Size Yes 116794 Bytes

Max PDU Send Size (larger PDUs will never be sent, even if the receiver supports a larger Max PDU Receive Size. If the receiver supports a smaller Max PDU Receive Size then the Max PDU Send Size will be reduced accordingly for the duration of the Association. Max PDU Receive Size information is exchanged during DICOM Association Negotiation in the Maximum Length Sub-Item of the A-ASSOCIATION-RQ and A-ASSOCIATE-AC)

No 116794 Bytes

Time-out waiting for a acceptance or rejection response to an Association Request (Application Level Timeout)

Yes 10 s

Time-out waiting for a response to an Association release request (Application Level Timeout)

Yes 30 s

Time-out waiting for completion of a TCP/IP connect request (Low-level timeout)

Yes 15 s

Time-out awaiting a Response to a DIMSE Request (Low-Level Timeout) Yes 1200 s

Time-out for waiting for data between TCP/IP-packets (Low Level Timeout)

Yes 30 s

Storage Parameters

Storage SCU time-out waiting for a response to a C-STORE-RQ Yes 30 s

Number of times a failed send job may be retried Yes 10 (Failed send jobs are not retried)

Delay between retrying failed send jobs Yes 10 s

Maximum number of simultaneously initiated Associations by the Storage AE

Yes 3

Supported Transfer Syntaxes (separately configurable for each remote AE)

No Implicit VR Little Endian Explicit VR Little Endian

Modality Worklist Parameters

Modality Worklist SCU time-out waiting for the final response to a C-FIND-RQ

Yes 600 s

Maximum number of Worklist Items No N/A

Supported Transfer Syntaxes for Modality Worklist No Implicit VR Little Endian Explicit VR Little Endian

Delay between automatic Worklist Updates Yes 1 min


Parameter Configurable (Yes/No)

Default Value

Query Worklist for specific Scheduled Station AE Title Yes UNO

Query Worklist for specific Modality Value Yes DX

5. Media Interchange

5.1. Implementation Model

5.1.1. Application Data Flow

Figure 5.1-1 - Application Data Flow Diagram for Media Storage

Export to CD-R

Offline-Media Application

Entity

CD-R Storage Medium

— The Offline-Media Application Entity exports images to a CD-R Storage medium. It is associated with the local real-world activity “Export to CD-R”. “Export to CD-R” is performed upon user request for the images in selected studies.

5.1.2. Functional Definition of AEs

5.1.2.1. Functional Definition of Offline-Media Application Entity

Activation of the “Export to CD-R” icon or menu entry will pass the currently selected studies to the

Offline-Media Application Entity. The SOP Instances associated with the selection will be collected into

one or more export jobs. The contents of each export job will be written to a single CD-R media.

5.1.3. Sequencing of Real-World Activities

At least one image must exist and be selected before the Offline-Media Application Entity can be

invoked. The operator can insert a new CD-R media at any time before or after invocation of the Offline-

Media Application Entity. The Offline-Media Application Entity will wait indefinitely for a media to be

inserted before starting to write to the CD-R device. If no CD-R media is available the export job can be

canceled from the job queue.


5.1.4 File Meta Information Options

The implementation information written to the File Meta Header in each file is:

Table 5.1-1 - DICOM Implementation Class and Version for Media Storage



5.2. AE SPECIFICATIONS

5.2.1. Offline-Media Application Entity Specification

The Offline-Media Application Entity provides standard conformance to the Media Storage Service Class.

The Application Profiles and roles are listed below:

Table 5.2-1 - Application Profiles, Activities and Roles for Offline-Media

Application Profiles Supported Real World Activity Role

STD-GEN-CD Export to CD-R FSC

5.2.1.1. File Meta Information for the Application Entity

The Source Application Entity Title included in the File Meta Header is configurable (see section 5.4).

5.2.1.2. Real-World Activities

5.2.1.2.1. Activity – Export to CD-R

The Offline-Media Application Entity acts as an FSC when requested to export SOP Instances from the

local database to a CD-R medium.

When the user inserts an empty CD-R then the Export button will become active. The contents of the

export job will be written together with a corresponding DICOMDIR to a single-session CDR. Writing in

multi-session mode is not supported.

5.2.1.2.1.1 Media Storage Application Profiles

The Offline-Media Application Entity supports the STD-GEN-CD Application Profile.

5.2.1.2.1.1.1 Options

The Offline-Media Application Entity supports the SOP Classes and Transfer Syntaxes listed in the Table

below:


Table 5.2-2 - IODs, SOP Classes and Transfer Syntaxes for OfflineMedia

Information Object Definition SOP Class UID Transfer Syntax Transfer Syntax

UID

Media Storage Directory Storage 1.2.840.10008.1.3.10 Explicit VR Little Endian

1.2.840.10008.1.2.1

Digital X-Ray Image Storage – For

Presentation

1.2.840.10008.5.1.

4.1.1.1.1 Explicit VR Little Endian

1.2.840.10008.1.2.1

5.3 Augmented and Private Application Profiles

UnoSM™ does not support any augmented for private application profiles.

5.4 Media Configuration

All local applications use the AE Titles configured via the Service/Installation Tool. The Application Entity

Titles configurable for Media Services are listed in the Table below:

Table 5.4-1 - AE Title Configuration Table

Application Entity Default AE Title

Offline-Media UNOSM


6. Support of Character Sets All UNOSM™ DICOM applications support the

ISO_IR 100 (ISO 8859-1:1987 Latin Alphabet No. 1 supplementary set)


7. Security UNOSM™ does support user security through logins. User accounts are setup in the Admin -> Users

setting screen.

As far as any unauthorized access, it is assumed that UnoSM™ is used within a secured environment. It

is assumed that a secured environment includes at a minimum:

a. Firewall or router protections to ensure that only approved external hosts have network access to UNOSM™.

b. Firewall or router protections to ensure that UnoSM™ only has network access to approved external hosts and services.

c. Any communication with external hosts and services outside the locally secured environment use appropriate secure network channels (e.g. such as a Virtual Private Network (VPN))

Other network security procedures such as automated intrusion detection may be appropriate in some

environments. Additional security features may be established by the local security policy and are

beyond the scope of this conformance statement.

8. Annexes

8.1.1 Created SOP Instances

Table 8.1-1 specifies the attributes of a DX Image transmitted by the UNOSM™ storage application.

Table 8.1-2 specifies the attributes of a Grayscale Softcopy Presentation State transmitted by the

UnoSM™ storage application.

The following tables use a number of abbreviations. The abbreviations used in the “Presence of …”

column are:

VNAP Value Not Always Present (attribute sent zero length if no value is present)

ANAP Attribute Not Always Present

ALWAYS Always Present

EMPTY Attribute is sent without a value

The abbreviations used in the “Source” column:

MWL the attribute value source Modality Worklist

USER the attribute value source is from User input

AUTO the attribute value is generated automatically

CONFIG the attribute value source is a configurable parameter


NOTE: All dates and times are encoded in the local configured calendar and time. Date, Time and Time zone are configured using the Service/Installation Tool.

8.1.1.1. DX Image IOD

Table 8.1-1 - IOD of created DX SOP Instances

IE Module Reference Presence of Module

Patient Patient C.7.1.1 ALWAYS

Study General Study C.7.2.1 ALWAYS

Patient Study C.7.2.2 ALWAYS

Series General Series C.7.3.1 ALWAYS

DX Series C.8.11.1 ALWAYS

Equipment General Equipment C.7-8 ALWAYS

Image General Image C.7.6.1 ALWAYS

Display Shutter C.7.6.11 Only if Auto Shutter turned on or manual shutter

DX Anatomy Imaged C.8.11.2 ALWAYS

DX Image C.8.11.3 ALWAYS

DX Detector C.8.11.4 ALWAYS

DX Positioning C.8.11.5 ALWAYS

X-Ray Acquisition Dose C.8.7.8 If generator connected or user entered

SOP Common C.12.1 M


8.1.1.2. Common Modules

Table 8.1-2 - Patient Module of created SOP Instances

Attribute Name Tag VR Value Presence of Value

Source

Patient’s Name (0010,0010) PN

From Modality Worklist or user input. Values supplied via Modality Worklist will be entered as received. Values supplied via user input will contain all 5 components (some possibly empty). . Maximum 64 characters.

VNAP MWL/ USER

Patient ID (0010,0020) LO From Modality Worklist or user input. Maximum 64 characters.

VNAP MWL/ USER

Patient’s Birth Date (0010,0030) DA From Modality Worklist or user input

VNAP MWL/ USER

Patient’s Sex (0010,0040) CS From Modality Worklist or user input

VNAP MWL/ USER

Table 8.1-3 - General Study Module of created SOP Instances


Source

Study Instance UID (0020,000D) UI From Modality Worklist or generated by device

ALWAYS MWL/ AUTO

Study Date (0008,0020) DA <yyyymmdd> ALWAYS AUTO

Study Time (0008,0030) TM <hhmmss> ALWAYS AUTO

Referring Physician’s Name

(0008,0090) PN From Modality Worklist VNAP MWL/ USER

Physician(s) of Record (0008,1048) PN From Modality Worklist or user input

VNAP MWL/ USER

Study ID (0020,0010) SH Requested Procedure ID from Worklist or User Input

VNAP MWL/ USER

Accession Number (0008,0050) SH From Modality Worklist or user input

VNAP MWL/ USER

Study Description (0008,1030) LO Comment text box in study list. Maximum 1024 characters.

VNAP USER/MWL


Table 8.1-4 - Patient Study Module of created SOP Instances


Source

Admitting Diagnosis Description

(0008,1080) LO From Modality Worklist VNAP MWL

Patient’s Age (0010,1010) AS Calculated from Date of Birth input on base of actual Date

ALWAYS AUTO

Patient’s Weight (0010,1030) DS From Modality Worklist or user input

VNAP MWL/ USER

Table 8.1-5 - General Series Module of created SOP Instances


Source

Modality (0008,0060) CS RF ALWAYS AUTO

Series Instance UID (0020,000E) UI Generated by device ALWAYS AUTO

Series Number (0020,0011) IS Generated by device ALWAYS AUTO

Series Date (0008,0021) DA <yyyymmdd> ALWAYS AUTO

Series Time (0008,0031) TM <hhmmss> ALWAYS AUTO

Performing Physician’s Name

(0008,1050) PN Physician field in Study list. Maximum 64 characters.

VNAP USER

Protocol Name (0018,1030) LO Organ program ALWAYS AUTO

Series Description (0008,103E) LO Organ from Study list. Maximum 512 characters.

VNAP USER

Operator’s Name (0008,1070) PN Operator field in Study list. Maximum 64 characters.

VNAP USER

Request Attributes Sequence

(0040,0275) SQ Zero or 1 item will be present ALWAYS AUTO

>Requested Procedure ID (0040,1001) SH From Modality Worklist VNAP MWL

>Scheduled Procedure Step ID

(0040,0009) SH From Modality Worklist VNAP MWL

>Scheduled Procedure Step Description

(0040,0007) LO From Modality Worklist VNAP MWL

>Scheduled Protocol Code Sequence

(0040,0008) SQ From Modality Worklist VNAP MWL

Table 8.1-6 - General Equipment Module of created SOP Instances

Attribute Name

Tag VR Value Presence of Value

Source

Manufacturer (0008,0070) LO Cuattro, LLC ALWAYS AUTO

Institution (0008,0080) LO From Configuration VNAP CONFIG


Name

Station Name (0008,1010) SH From Configuration ALWAYS CONFIG

Manufacturer’s Model Name

(0008,1090) LO Cuattro Uno SM ALWAYS AUTO

Device Serial Number

(0018,1000) LO From Configuration ALWAYS CONFIG

Software Version

(0018,1020) LO From Configuration ALWAYS CONFIG

8.1.1.3. DX Image Modules

Table 8.1-7 - General Image Module of created DX SOP Instances

Attribute Name


Source

Instance Number

(0020,0013) IS Generated by device ALWAYS AUTO

Patient Orientation

(0020,0020) CS Zero length EMPTY AUTO

Content Date (0008,0023) DA <yyyymmdd> ALWAYS AUTO

Content Time (0008,0033) TM <hhmmss> ALWAYS AUTO

Acquisition Number

(0020,0012) IS Generated by device ALWAYS AUTO

Image Comments

(0020,4000) LT From user input. Maximum 1024 characters.

VNAP USER

Anatomic Region Sequence

(0008,2218) SQ From user input. ALWAYS USER

> Include ‘Code Sequence Macro’ Baseline Context ID is 4009 (see also section B8.6)

Table 8.1-8 - Image Pixel Module of created DX SOP Instances

Attribute Name


Source

Pixel Data (7FE0,0010) OW The Pixel Data itself does not contain any burned-in annotation.

ALWAYS AUTO


Table 8.1-9 - Display Shutter Module of created DX SOP Instances

Attribute Name Tag VR Value Presence of

Value Sourc

e

Shutter Shape (0018,1600) CS If shutter applied: RECTANGULAR

ANAP AUTO

Shutter Left Vertical Edge (0018,1602) IS If RECTANGULAR shutter applied

ANAP AUTO

Shutter Right Vertical Edge

(0018,1604) IS If RECTANGULAR shutter applied

ANAP AUTO

Shutter Upper Horizontal Edge


ANAP AUTO

Shutter Lower Horizontal Edge


ANAP AUTO

Table 8.1-10 - DX ANATOMY IMAGED OF CREATED DX SOP INSTANCES


Value Sourc

e

Image Laterality (0020,0062) CS From user input ANAP AUTO

Table 8.1-11 - DX IMAGE OF CREATED DX SOP INSTANCES


Value Source

Image Type (0008,0008) CS ORIGINAL\PRIMARY ALWAYS AUTO

Samples per Pixel (0028,0002) US 1 ALWAYS AUTO

Photometric Interpretation

(0028,0004) CS

MONOCHROME2, unless inverted by user

ALWAYS AUTO

Bits Allocated (0028,0100) US 16 ALWAYS AUTO

Bits Stored (0028,0101) US 16 ALWAYS AUTO

High Bit (0028,0102) US 15 ALWAYS AUTO

Pixel Representation (0028,0103) US 0 ALWAYS AUTO

Pixel Intensity Relationship

(0028,1040) CS LIN ALWAYS AUTO

Pixel Intensity Relationship Sign

(0028,1041) SS -1 ALWAYS AUTO

Presentation LUT Shape

(2050,0020) CS IDENTITY ALWAYS AUTO

Lossy Image Compression

(0028,2110) CS 00 ALWAYS AUTO

Patient Orientation (0020,0020) CS R\P ALWAYS AUTO

Burned In Annotation (0028,0301) CS NO ALWAYS AUTO


Window Center (0028,1050) DS

Generated by device, can be overridden by user.

ALWAYS AUTO/USER

Window Width (0028,1051) DS

Generated by device, can be overridden by user.

ALWAYS AUTO/USER

Window Center & Width Explanation

(0028,1055) LO Default ALWAYS AUTO

Table 8.1-12 - DX DETECTOR created DX SOP Instances


Value Sourc

e

Imager Pixel Spacing (0018,1164) DS

Generated by device.

ALWAYS AUTO

Table 8.1-13 - DX POSITIONING CREATED DX SOP INSTANCES


Value Source

View Code Sequence (0054,0220) SQ


ANAP CONFIG

> Code Value (0008,0100) SH


ANAP CONFIG

> Coding Scheme Designator

(0008,0102) SH SNM3 ANAP CONFIG

> Code Meaning (0008,0104) LO


ANAP CONFIG

Table 8.1-14 - X-Ray Acquisition Dose CREATED DX SOP INSTANCES


Value Source

KVP (0018,0060) DS

From generator setting or user entered.

ANAP CONFIG /USER

X-Ray Tube

Current

(0018,1151)

IS From generator setting or user entered.

ANAP CONFIG /USER

Exposure Time (0018,1150) IS


ANAP CONFIG /USER

Exposure in µAs (0018,1153) IS


ANAP CONFIG /USER


Table 8.1-15 - SOP Common Module of created DX SOP Instances

Attribute Name


Source

Specific Character Set

(0008,0005) CS “ISO_IR 100” ALWAYS AUTO

SOP Class UID

(0008,0016) UI 1.2.840.10008.5.1.4.1.1.1.1 ALWAYS AUTO

SOP Instance UID

(0008,0018) UI Generated by device ALWAYS AUTO

8.1.2. Used Fields in received IOD by application

The UnoSM™ storage application does not receive SOP Instances. The usage of attributes received via

Modality Worklist is described in section 4.2.2.3.1.3.

8.1.3. Attribute mapping

The relationships between attributes received via Modality Worklist and stored in acquired images are

summarized in Table 8.1-31. The format and conventions used in Table 99 are the same as the

corresponding table in DICOM Part 4, Annex M.6 [DICOM].

Table 8.1-16 - Attribute Mapping Between Modality Worklist AND Image

Modality Worklist Image IOD

Patient Name Patient Name

Patient ID Patient ID

Patient’s Birth Date Patient’s Birth Date

Patient’s Sex Patient’s Sex

Patient’s Weight Patient’s Weight

Referring Physician’s Name Referring Physician’s Name

---- ----

Study Instance UID Study Instance UID

Referenced Study Sequence Referenced Study Sequence

Accession Number Accession Number

---- Request Attributes Sequence

Requested Procedure ID >Requested Procedure ID

Requested Procedure Description

Scheduled Procedure Step ID >Scheduled Procedure Step ID

Scheduled Procedure Step Description >Scheduled Procedure Step Description

Scheduled Protocol Code Sequence >Scheduled Protocol Code Sequence


---- ----

Scheduled Performing Physician’s Name Performing Physician’s Name

Requested Procedure Code Sequence ----

---- Protocol Name

8.1.4. Coerced/Modified Fields

The Modality Worklist AE will truncate attribute values received in the response to a Modality Worklist

Query if the value length is longer than the maximum length permitted by the attribute’s VR.

8.2. Data Dictionary of Private Attributes

The Private Attributes added to created SOP Instances are listed in the Table below. UNOSM™ reserves

blocks of private attributes in group 5BE7. Further details on usage of these private attributes are

contained in Section 8.1.

Table 8.2-1 - Data Dictionary of Private Attributes

Tag Attribute Name VR VM

(5BE7,00E7) Private Creator (Cuattro Private Block) LO 1

(5BE7,E703) Patient Create DateTime DT 1

(5BE7,E705) Patient Category Size (e.g. Child, Adult, Large) LO 1

(5BE7,E706) Image View LO 1

(5BE7,E707) Image Anatomy LO 1

(5BE7,E708) Image Enhancements (enhancements applied to an image) LO 1

(5BE7,E709) Image Laterality Extended ST 1

(5BE7,E70B) Web Access Code LO 1

8.3. Coded Terminology and Templates

The Workflow AE is capable of supporting arbitrary coding schemes for Procedure and Protocol Codes.

The contents of Requested Procedure Code Sequence (0032,1064) and Scheduled Protocol Code

Sequence (0040,0008) supplied in Worklist Items will be mapped to Image IOD as described in Table 8.1-

31. During installation, a service technician will establish a mapping between the site-specific codes and

the Protocol Names used internally to identify acquisition protocols.

The contents of Anatomic Region Sequence (0008,2218) in generated images will be filled with an

anatomic code selected by the user from a catalog. The default catalog of anatomic codes corresponds

to Context Group 4009 but can be extended using the Service/Installation Tool.


8.4. Grayscale Image Consistency

Currently no specific Grayscale Image consistency verification.

8.5. Standard Extended / Specialized / Private SOP Classes

No Specialized or Private SOP Classes are supported.

8.6. Private Transfer Syntaxes

No Private Transfer Syntaxes are supported.

unosm dicom conformance statement - cuattro

Documents