DICOM Conformance Statement

CLARUSTM 500 and CLARUSTM 700
Version 1.1.1
Carl Zeiss Meditec, Inc.
5160 Hacienda Drive
Dublin, CA 94568
USA

    1 Conformance Statement Overview

CLARUS 500 and CLARUS 700 (both referred to as CLARUS in this document unless distinction is
explicitly made) are non-contact, high-resolution imaging devices for invivo imaging of the human eye.
Imaging modes include:

• True color reflectance imaging
• Infrared reflectance imaging (IR)
• Fundus autofluorescence with green or blue excitation (FAF-G and FAF-B)
• Fluorescein Angiography (FA) – CLARUS 700 only
• Stereo imaging
• External eye imaging

CLARUS consists of an image acquisition modality and review application. The acquisition modalities
enables examination of patient’s eye, while CLARUS review software enables you to view, analyze and manage CLARUS data on a personal computer. It provides all the CLARUS instrument functionality, except exam acquisition, in a remote location.
The CLARUS Application Software allows to:

• query modality worklist
• query patients and data
• create report
• perform exam
• store exam
• create report
• retrieve exam
• delete data
• DICOM file import
• DICOM file export
• merge of patients & reassign of exams

This document is structured as suggested in the DICOM Standard (PS 3.2: Conformance).
Table 1-1 Network Services Supported

1Note : C-FIND extended negotiation is offered. Relational-query support is required by the SCP.
2Note : Only acts as SCP when a C-Move-RQ was initiated first and this association is still open.

3Note : CLARUS does not transmit VL Photographic Image IODs via DICOM network. It provides
function to DICOM retrieve and import VISUCAM / VISPUPAC DICOM VL Photographic Image files
from local, external or network drive.
4Note : CLARUS acts as Storage SCU for OP 8 Bit Images generated by CLARUS itself. However, it
performs DICOM retrieve and file import only for those OP 8 Bit Images generated by VISUCAM /
VISPUPAC.
CLARUS does not support Media Interchange.

2 Table of Contents

1 Conformance Statement Overview …………………………………………………………………………………………..2
2 Table of Contents……………………………………………………………………………………………………………..4
3 Introduction ……………………………………………………………………………………………………………………6
3.1 Revision History ……………………………………………………………………………………………………….6
3.2 Audience……………………………………………………………………………………………………………….6
3.3 Remarks ……………………………………………………………………………………………………………….6
3.4 Definitions and Terms …………………………………………………………………………………………………6
3.5 Abbreviations…………………………………………………………………………………………………………..8
3.6 References …………………………………………………………………………………………………………….9
4 Networking…………………………………………………………………………………………………………………..10
4.1 Implementation Model ………………………………………………………………………………………………. 10
4.1.1 Application Data Flow………………………………………………………………………………………… 10
4.1.2 Functional Definition of AEs …………………………………………………………………………………. 12
4.1.2.1 Functional Definition of CLARUS ……………………………………………………………………….. 12
4.1.3 Sequencing of Real-World Activities ………………………………………………………………………… 12
4.1.3.1 Acquisition Modality activities……………………………………………………………………………. 13
4.1.3.2 Scheduled case with Acquisition Modality………………………………………………………………. 15
4.1.3.3 Unscheduled case……………………………………………………………………………………….. 16
4.2 AE Specifications……………………………………………………………………………………………………. 17
4.2.1 CLARUS AE Specification …………………………………………………………………………………… 17
4.2.1.1 SOP Classes …………………………………………………………………………………………….. 17
4.2.1.2 Associations Policies……………………………………………………………………………………..17
4.2.1.2.1 General………………………………………………………………………………………………. 17
4.2.1.2.2 Number of Associations …………………………………………………………………………….. 17
4.2.1.2.3 Asynchronous Nature ……………………………………………………………………………….. 18
4.2.1.2.4 Implementation Identifying Information……………………………………………………………… 18
4.2.1.3 Association Initiation Policy ……………………………………………………………………………… 18
4.2.1.3.1 Activity – Verify Communication…………………………………………………………………….. 18
4.2.1.3.2 Activity – Query Modality Worklist ………………………………………………………………….. 19
4.2.1.3.3 Activity – Query Patients and Data ………………………………………………………………….. 29
4.2.1.3.4 Activity – Retrieve Exam…………………………………………………………………………….. 36
4.2.1.3.5 Activity – Perform Exam …………………………………………………………………………….. 44
4.2.1.3.6 Activity – Store Exam ……………………………………………………………………………….. 45
4.2.1.3.7 Activity – Create Report …………………………………………………………………………….. 49
4.2.1.3.8 Activity – Merge and Reassign ……………………………………………………………………… 50
4.2.1.3.9 Activity – DICOM File Import ………………………………………………………………………… 50
4.2.1.3.10 Activity – DICOM File Export ……………………………………………………………………. 50
4.2.1.3.11 Activity – Delete data……………………………………………………………………………. 51
4.2.1.4 Association Acceptance Policy ………………………………………………………………………….. 53
4.2.1.4.1 Activity – Verify Communication…………………………………………………………………….. 53
4.2.1.4.2 Activity – Store Exam ……………………………………………………………………………….. 53
4.2.1.4.1 Activity – Create Report …………………………………………………………………………….. 54
4.2.1.4.2 Activity – Retrieve Exam…………………………………………………………………………….. 55
4.3 Network Interfaces ………………………………………………………………………………………………….. 56
4.3.1 Physical Network Interface…………………………………………………………………………………… 56
4.3.2 Additional Protocols ………………………………………………………………………………………….. 56
4.3.3 IPv4 and IPv6 Support……………………………………………………………………………………….. 56
4.4 Configuration………………………………………………………………………………………………………… 56
4.4.1 AE Title/Presentation Address Mapping …………………………………………………………………….. 56
4.4.1.1 Local AE Titles …………………………………………………………………………………………… 56
4.4.1.2 Remote AE Titles ………………………………………………………………………………………… 56
4.4.2 Parameters …………………………………………………………………………………………………… 56
4.4.2.1 General Parameters………………………………………………………………………………………56
Document: DICOM_Conformance_Statement_CLARUS_500_700_V1.1.1.Docx Page 5 of 87
Copyright: © Carl Zeiss Meditec Inc. EN_31_200_0170I Revision: I
5 Media Interchange…………………………………………………………………………………………………………..59
6 Support of Character Sets…………………………………………………………………………………………………..60
7 Security………………………………………………………………………………………………………………………61
7.1 Security Profiles …………………………………………………………………………………………………….. 61
7.1.1 Basic Application Level Confidentiality Profile ………………………………………………………………. 61
7.1.2 ASSOCIATION LEVEL SECURITY …………………………………………………………………………. 62
7.1.3 APPLICATION LEVEL SECURITY………………………………………………………………………….. 62
8 Annexes ……………………………………………………………………………………………………………………..63
8.1 IOD Contents………………………………………………………………………………………………………… 63
8.1.1 Created SOP Instance(s) …………………………………………………………………………………….63
8.1.1.1 Ophthalmic Photography 8 Bit Image Information Object Definition …………………………………… 64
8.1.1.2 Encapsulated PDF Information Object Definition………………………………………………………..65
8.1.1.3 Raw Data Information Object Definition…………………………………………………………………. 66
8.1.1.4 Common Modules ……………………………………………………………………………………….. 67
8.1.1.5 Modules “Series” of Created OP 8 Bit Image SOP Instances ………………………………………….. 69
8.1.1.6 Modules “Series” of Created Raw Data SOP Instances………………………………………………… 70
8.1.1.7 Module “Series” of Created ePDF SOP Instances ……………………………………………………… 71
8.1.1.8 Module “Frame of Reference” of Created OP 8 Bit Image SOP Instances …………………………….72
8.1.1.9 Module “Equipment” of Created ePDF SOP Instances…………………………………………………. 72
8.1.1.10 Modules “Image” of Created OP 8 Bit Image SOP Instances ………………………………………….. 73
8.1.1.11 Modules “Raw Data” of Created Raw Data SOP Instances ……………………………………………. 79
8.1.1.12 Modules “Ecapsulated Document” of Created ePDF SOP Instances ………………………………….. 80
8.1.2 Usage of Attributes from Received IOD’s …………………………………………………………………… 82
8.1.3 Attribute Mapping…………………………………………………………………………………………….. 82
8.1.4 Coerced/Modified Files ……………………………………………………………………………………….83
8.2 Data Dictionary of Private Attributes ……………………………………………………………………………….. 84
8.3 Coded Terminology and Templates ………………………………………………………………………………… 86
8.4 Greyscale Image Consistency ………………………………………………………………………………………86
8.5 Standard Extended / Specialized/ Private SOP Classes…………………………………………………………… 86
8.6 Private Transfer Syntaxes ………………………………………………………………………………………….. 86

3 Introduction

3.1 Revision History

3.2 Audience

This document is written for the people that need to understand how CLARUS will integrate into their healthcare facility. This includes both those responsible for overall imaging network policy and architecture, as well as integrators who need to have a detailed understanding of the DICOM features of the product. This document contains some basic DICOM definitions so that any reader may understand how this product implements DICOM features. However, integrators are expected to fully understand all the DICOM terminology, how the tables in this document relate to the product’sn functionality, and how that functionality integrates with other devices that support compatible DICOM features.

3.3 Remarks

The scope of this DICOM Conformance Statement is to facilitate integration between CLARUS and other DICOM products. The Conformance Statement should be read and understood in conjunction with the DICOM Standard. DICOM by itself does not guarantee interoperability. The Conformance Statement does, however, facilitate a first-level comparison for interoperability between different applications supporting compatible DICOM functionality. This Conformance Statement is not supposed to replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, the user should be aware of the following important issues:

• The comparison of different Conformance Statements is just the first step towards
  assessing interconnectivity and interoperability between the product and other DICOM
  conformant equipment.

• Test procedures should be defined and executed to validate the required level of
  interoperability with specific compatible DICOM equipment, as established by the
  healthcare facility.

3.4 Definitions and Terms

Informal definitions are provided for the following terms used in this Conformance Statement.
The DICOM Standard is the authoritative source for formal definitions of these terms.
Abstract Syntax
the information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) Class.
Examples: Verification SOP Class, Modality Worklist Information Model Find SOP Class, Computed Radiography Image Storage SOP Class.
Application Entity (AE)
an end point of a DICOM information exchange, including the DICOM network or media interface software; i.e., the software that sends or receives DICOM information objects or messages. A single device may have multiple Application Entities.

Application Entity Title
the externally known name of an Application Entity, used to identify a DICOM application to other DICOM applications on the network.
Application Context
the specification of the type of communication used between Application Entities.

Example: DICOM network protocol.
Association
a network communication channel set up between Application Entities.
Attribute
a unit of information in an object definition; a data element identified by a tag. The information may be a complex data structure (Sequence), itself composed of
lower level data elements.
Examples: Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation (0028,0004), Procedure Code Sequence (0008,1032).
Information Object Definition (IOD)
the specified set of Attributes that comprise a type of data object; does not represent a specific instance of the data object, but rather a class of similar data
objects that have the same properties. The Attributes may be specified as Mandatory (Type 1), Required but possibly unknown (Type 2), or Optional (Type 3), and there may be conditions associated with the use of an Attribute (Types 1C and 2C). Examples: MR Image IOD, CT Image IOD, Print Job IOD.
Joint Photographic Experts Group (JPEG)
a set of standardized image compression techniques, available for use by DICOM applications.
Media Application Profile
the specification of DICOM information objects and encoding exchanged on removable media (e.g., CDs)
Module
a set of Attributes within an Information Object Definition that are logically related to each other.
Example: Patient Module includes Patient Name, Patient ID, Patient Birth Date, and Patient Sex.
Negotiation
first phase of Association establishment that allows Application Entities to agree on the types of data to be exchanged and how that data will be encoded.
Presentation Context
the set of DICOM network services used over an Association, as negotiated between Application Entities; includes Abstract Syntaxes and Transfer Syntaxes.
Protocol Data Unit (PDU)
a packet (piece) of a DICOM message sent across the network. Devices must specify the maximum size packet they can receive for DICOM messages.
Query Key

A input value for a query process. Query Keys denote the set of DICOM tags that
are sent from the SCU to SCP and thus control the query result.
Security Profile
a set of mechanisms, such as encryption, user authentication, or digital
signatures, used by an Application Entity to ensure confidentiality, integrity, and/or
availability of exchanged DICOM data

Service Class Provider (SCP)
role of an Application Entity that provides a DICOM network service; typically, a server that performs operations requested by another Application Entity (Service Class User).
Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP).

Service Class User (SCU)
role of an Application Entity that uses a DICOM network service; typically, a client.
Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU)
Service/Object Pair (SOP) Class
the specification of the network or media transfer (service) of a particular type of data (object); the fundamental unit of DICOM interoperability specification.
Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management.
Service/Object Pair (SOP) Instance
an information object; a specific occurrence of information exchanged in a SOP Class.
Examples: a specific x-ray image.
Tag
a 32-bit identifier for a data element, represented as a pair of four digit hexadecimal numbers, the “group” and the “element”. If the “group” number is odd, the tag is for a private (manufacturer-specific) data element.
Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element] Transfer Syntax
the encoding used for exchange of DICOM information objects and messages.
Examples: JPEG compressed (images), little endian explicit value representation.
Unique Identifier (UID)
a globally unique “dotted decimal” string that identifies a specific object or a class of objects; an ISO-8824 Object Identifier.
Examples: Study Instance UID, SOP Class UID, SOP Instance UID.
Value Representation (VR)
the format type of an individual DICOM data element, such as text, an integer, a person’s name, or a code. DICOM information objects can be transmitted with
either explicit identification of the type of each data element (Explicit VR), or without explicit identification (Implicit VR); with Implicit VR, the receiving
application must use a DICOM data dictionary to look up the format of each data element.

3.5 Abbreviations

Table 3-1 Abbreviations used in this document

3.6 References

NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (DICOM) Standard,
National Electrical Manufacturers Association, Rosslyn, VA, USA (available free at http://medical.nema.org/)
Integrating the Healthcare Enterprise (IHE) EYECARE Technical Framework, rev 4.0, 2016 (available
free at http://www.ihe.net/Technical_Framework/index.cfm).

4.1 Implementation Model

4.1.1 Application Data Flow

Figure 1 CLARUS Application Software as Acquisition Modality

Figure 2 CLARUS Application Software as Review Station

4.1.2 Functional Definition of AEs

4.1.2.1 Functional Definition of CLARUS

CLARUS is a non-contact, high-resolution imaging device for invivo imaging of the human eye.
Imaging modes include:

• True color reflectance imaging
• Infrared reflectance imaging (IR)
• Fundus autofluorescence with green or blue excitation (FAF-G and FAF-B)
• Fluorescein Angiography (FA) – CLARUS 700 only
• Stereo imaging
• External eye imaging

The CLARUS consists of an image acquisition modality and review application. The acquisition
modalities enables examination of patient’s eye, while CLARUS review software enables you to view,
analyze and manage CLARUS data on a personal computer. It provides all the CLARUS instrument
functionality, except exam acquisition, in a remote location.
The CLARUS Application Software allows to:
• query modality worklist
• query patients and data
• perform exam
• store exam
• create report
• retrieve exam
• delete data
• DICOM file import
• DICOM file export
• merge of patients & reassign of exams
The CLARUS Software allows performing a verification of the configured AEs. The result of this
verification contains information about the supported SOP Classes and Transfer Syntaxes.
The CLARUS Software logs extensive information about the DICOM operations to its log file.

4.1.3 Sequencing of Real-World Activities

To realize the real world activities, the different entities work together. The sequence diagrams shall
depict the intended workflow.

The diagrams use slightly modified UML symbols. The asynchronous call is not depicted as suggested in UML. Some objects do have more than one dashed line. It symbolizes more than one thread.

4.1.3.1 Acquisition Modality activities

Query Modality Worklist
When the patient arrives at the CLARUS, the operator queries the worklist. The user can invoke this by simply selecting the “Today” Tab in the main view which
lists all patients scheduled for today for this instrument (identified by the instrument’s AE Title) and scheduled procedure step start date from today. The default parameters used for this “Today’s” Query are configurable. See Table 4-37 Configuration Parameters for more details. For more specific worklist queries the
“Advanced” and then “Scheduled Patients” button can be used. In either way the operator can select a patient from the result list and furthermore select a requested procedure to proceed with data acquisition. According to the transferred data CLARUS creates an entry in the local database. CLARUS does not support multiple Scheduled Procedure Steps in one Requested
Procedure. Note: In case of multiple Scheduled Procedure Steps within one Requested
Procedure only the first Scheduled Procedure Step will be shown: Scheduled Procedure Step Start Time1 = 2pm Scheduled Procedure Step Start Time2 = 4pm
Only Scheduled Procedure Step scheduled for 2 pm will be shown. Query patients and data
When the patient arrives at the CLARUS, the operator can search patients and data stored at a remote AE. This can be done by using the “Quick Search” in the
main screen or by using “Advanced” and then the “All Patients” for a more detailed search. Any matching results will be listed in patient list. Only data supported by CLARUS will be listed (see chapter 4.2.1.3.4 for more details on supported data) This activity generates an unscheduled case. The operator can then select the patient for data acquisition or analysis.
Perform Exam
When a patient or worklist item is selected the operator selects an acquisition type and then performs the exam on the patient’s eye. The Application Software allows
users to review the acquired data, and elaborate the images before permanently saving the scan results.
Store Exam

Based on the selected Export Mode, the acquired data will be sent to the configured storage provider. If Export Mode “Session” is selected, CLARUS sends data acquired in the current session right after the acquisition session is completed. If “Shutdown” is selected, storage of all unarchived exam data is triggered during CLARUS shutdown.
When archiving to “FORUM/PACS Server”, all Sensor data (Raw Data IOD), Elaboration Parameter (Raw Data IOD), and OP 8Bit Image IODs are sent.
When archiving to “DICOM EMR”, only OP 8-Bit Image IODs can be sent. Storage Commitment are requested only for Sensor Data (Raw Data IOD).
Sensor data (Raw Data IOD) is the data scanned by the instrument. Elaboration Parameter (Raw Data IOD) includes image processing parameters, annotations
and comments that are generated by the device (default values) or added/modified by users during the review.
OP 8Bit Image IOD carries the image generated from the Sensor Raw Data for display purpose.

Create Reports
This is an optional on-demand activity. The operator can create and review a report based on the images displayed on the review screen. All the processing
parameters and annotations are applied. The reports are created on the fly. The user can print and/or save the created report. The application will send the report to the storage provider if it is configured.
Retrieve Exam
When a patient is selected from the main screen, CLARUS retrieves exams of the selected patient. It is to be noted that only Sensor data and Elaboration Parameter Raw Data IODs as well as VISUCAM Images (VL Photographic Images and OP 8 Bit Images) are retrieved.

Delete Data
The activity “Delete data” can either be invoked manually by the operator or triggered automatically by software application. Typically this can be invoked for
single exam or complete patient data. Manual invocation: The operator can invoke this activity from the “Patient” screen by pressing the “Delete” button shown for a certain measurement, a complete group of
measurements or a patient. When connected to a DICOM network, an instance or a patient cannot be removed from the modality until the storage to a remote AE is successfully completed and committed.
Optionally, the operator can select a patient, navigate to the Analyze screen to delete selected exams. Manually triggered deletion of data is performed immediately.
Automatic invocation: Automatically triggered deletion is done during the shutdown process and will be performed for any instance order than certain period (setting ExamCacheTime, default 14 days) where the storage to a remote AE is successfully completed and committed. Patient demographic data will only be deleted from the modality after all related storage instances have been successfully deleted.
DICOM File Import
This Activity allows import of exams from a disk attached to the device. After import those exams will be added to the local database. The Operator can trigger “Import” from “Specific Settings” at any time if no other activity is in progress. During this activity, CLARUS imports Raw Data IODs (Sensor data and
Elaboration Parameter) created by other CLARUS devices. It can also import VL Photographic Images created by VISUCAM.
DICOM File Export
This Activity allows export of exams to a local disk attached to the device. The Operator can trigger “export” from “Specific Settings”, and export all exams of the selected patients. The User can also export selected exams of a patient from the Analyze screen.
During this activity, only exams created by CLARUS are exported.
Merge and Reassign
It is possible to merge a local patient into a patient imported via Modality Worklist or into a patient imported via Patient Root Query from a DICOM Query Provder.

The operator can also reassign a local exam to another patient.
4.1.3.2 Scheduled case with Acquisition Modality
The normal case is that the patient arrives at the front desk. There could be two possibilities at this point:

• The examination can be scheduled in advance or at the moment the patient arrives and will be obtained by CLARUS via Modality Worklist query.

In either case all patient and study related information is available at the day the examination takes
place. On CLARUS these patients appear in the “Todays” list in the main screen. This information is
used to take the examination.

Figure 3 Scheduled Case

4.1.3.3 Unscheduled case

In the unscheduled case the patient arrives immediately at the instrument, so that the patient was not registered at the front desk or the software does not support DICOM modality worklist. Thus the examination is not scheduled in the Modality Worklist. Patient demographics and study specific information has to be generated at the instrument itself. The situation is akin to the case if the Modality Worklist AE could not be reached due to network issues.
Patient demographics can be queried from the Query Service Class Provider. However, this should be considered as an exceptional way to obtain patient demographics.

Figure 4 Unscheduled Case

4.2 AE Specifications

4.2.1 CLARUS AE Specification
4.2.1.1 SOP Classes
Table 4-1 SOP Classes for CLARUS AE

1Note : C-FIND extended negotiation is offered. Relational-query support is required by the SCP.
2Note : Only acts as SCP when a C-Move-RQ was initiated first and this association is still open.
3Note : CLARUS does not transmit VL Photographic Images IODs via DICOM network. It provides
function to DICOM retrieve and import VISUCAM / VISPUPAC DICOM VL Photographic Image files
from local, external or network drive.
4Note : CLARUS acts as Storage SCU for OP 8 Bit images generated by CLARUS itself. However, it
performs DICOM retrieve and file import only for those OP 8 Bit Images generated by VISUCAM /
VISPUPAC.

4.2.1.2 Associations Policies

4.2.1.2.1 General

The DICOM standard Application Context Name for DICOM 3.0 is always proposed:

Table 4-2 DICOM Application Context

Application Context Name 1.2.840.10008.3.1.1.1

4.2.1.2.2 Number of Associations

The number of simultaneous associations depends on the usage profile. At a certain point of time
there might be active simultaneously:

• 1 association for Verification
• 1 association for Storage
• 1 association for Storage Commitment
• 1 association for Query/Retrieve – MOVE
• n associations for Modality Worklist – FIND, depending on whether search criteria are changed while a previous query is still active (no response yet)
• n associations for Query/Retrieve – FIND, depending on whether search criteria are changed while a previous query is still active (no response yet)

Table 4-3 Number of associations

4.2.1.2.3 Asynchronous Nature

CLARUS Application Software does not support asynchronous communication (multiple outstanding
transactions over a single Association).

4.2.1.2.4 Implementation Identifying Information

Table 4-4 DICOM implementation class and version

4.2.1.3 Association Initiation Policy

4.2.1.3.1 Activity – Verify Communication
4.2.1.3.1.1 Description and Sequencing of Activities

This activity is available during the configuration phase. It facilitates the setup and management of the
DICOM Application Entities. The user can test the application level communication between instrument’s software Application Entity and its peer DICOM Application Entities. During one test call, all peer DICOM Application Entities are contacted.
In the association request CLARUS Application Software proposes not only Verification SOP Class,
but also all other SOP Classes as supported by the instrument’s DICOM interface. The association is established when the peer DICOM entity accepts the verification related presentation context. In a sub-sequent step a C-ECHO message is exchanged.
The results of the “Verify Communication” activity are shown to the user as success or failure. For e. g.
a Storage Provider not only the Verification information is evaluated, but also the acceptance of the
proposed presentation context comprising the respective Storage SOP Classes.

4.2.1.3.1.2 Proposed Presentation Contexts

Following presentation contexts are offered for each initiated association. During this activity the
Application Software uses only o

Verification with Transfer Syntax ILE as SCU

Table 4-5 Proposed Presentation Contexts for Activity Verify

Communication

1Note : C-FIND extended negotiation is offered. Relational-query support is required by the SCP.
2Note : Only acts as SCP when a C-Move-RQ was initiated first and this association is still open.
3Note : CLARUS does not transmit VL Photographic Image IODs via DICOM network. It provides function to DICOM retrieve and import VISUCAM / VISPUPAC DICOM VL Photographic Image files
from local, external or network drive.
4Note : CLARUS acts as Storage SCU for OP 8 Bit Images generated by CLARUS itself. However, it
performs DICOM retrieve and file import only for those OP 8 Bit Images generated by VISUCAM /
VISPUPAC.

4.2.1.3.1.3 SOP Specific Conformance for Verification SOP Class

The CLARUS Application Software provides standard conformance.

4.2.1.3.2 Activity – Query Modality Worklist

The worklist contains scheduling information for patients. Query Modality Worklist is used to search for
the right scheduling information for this instrument. An operator has two options to perform this activity.

4.2.1.3.2.1 Description and Sequencing of Activities

Option “Todays Patients query”

In this case, the Application Software performs a query with predefined query keys. These keys can be included/excluded in/from the worklist query by settings on “Specific Settings”→”Import Export Settings”→”Modality Worklist Query Settings For Today’s List”. The applied query keys are:

Table 4-6 Modality Worklist Query for Today’s Patients

All matching worklist items are subject to be imported into the local database.
This default query can be manually triggered by simply pressing the button in the header of the “Today” list. This default query is also triggered automatically in a configurable interval to keep the “Today” List up to date if option “Automatic MWL Update” is switched on.

Figure 5 Today’s Patients Query

![figure 5](https://manuals.plus/wp-

content/uploads/2020/12/figure-5-300x226.jpg)Select Requested Procedure

The worklist item planned next according to its Scheduled Procedure Step Start Date and Time will be pre-selected. The operator can choose to either start the
scan acquisition directly or choose another worklist item from the Today’s list before continuing with the acquisition. If the operator proceeds to acquire without
choosing any worklist item, the acquisition is associated with a worklist item with the earliest study date from the available worklist items.

Option “Interactive query”

The query keys of the “Interactive query” can be modified by the operator. To modify the query key the operator has to open the “Advanced” screen and use the
tab “Scheduled Patients”. This screen will provide all available search fields for the Modality Worklist search.
The operator can select the patient after the Modality Worklist search. In this case the patient will be added to the Today’s Patients list and the operator can perform
an acquisition.
Depending on the option “Automatic MWL Update” the workflow results in a scheduled or an unscheduled case.

Alternatively the operator can display the Modality Worklist Details for a selected
patient. In the Details screen the operator can select a Requested Procedure or
Scheduled Procedure Step and add the patient including the selected Requested
Procedure / Scheduled Procedure Step information.

Figure 6 Interactive Query

Trigger “Query Modality Worklist”

The activity “Query Modality Worklist” can be triggered by the operator at any time if no other activity is in progress. To invoke the query the operator has to use the “Scheduled Patients” tab from the “Advanced” search screen. It is meaningful to perform the query when the patient arrives at the modality. Then the worklist contains latest information.

Edit or modify query keys

The Modality Worklist query offers a GUI for interactive query. The “Station” is prefilled with the AE title configured for the Today’s Modality Worklist Query (see Table 4-37 Configuration Parameters) and the “Schedule date” is predefined with today. All predefined values can be changed. The operator can change or fill in search criteria in the shown dialog. For instance, the incomplete patient name or the patient ID can be used.

Trigger query

The operator triggers the search after he filled in search criteria. The Application Software sends a DICOM C-FIND request, which contains the search criteria. The
Application Software waits for the response from the partner Application Entity. The Application Software will accept up to a configurable number of matches. If
the number of received worklist items overstepped the configurable limit, the Application Software sends a C-CANCEL-RQ followed by a A-RELEASE-RQ to
the service provider and a message is displayed. Despite this warning, the operator gets results in the result-list. After receiving the response, the pick-list is updated. The result-list provides the most important information for a quick overview (see section Table 4-9 Attributes involved in Modality Worklist C-FIND request and response for the supported set
of tags). The operator can start over, redefine query keys and trigger the query again. This can be performed as often as required, until he or she finds the correct worklist item.

Select item in result-list

The operator can select a patient in the pick-list and return to the acquisition screen. Depending on the configuration of the predefined query keys and the
“Automatic or manual MWL Update” the workflow results in an unscheduled or a scheduled case. Please refer to step “Show Patient in main screen” for further
information.

Activate detailed view

The detailed view allows a closer look to all work items for the selected patient. Thus the operator can see more information about the patient, the Requested
Procedures and the Scheduled Procedure Steps planned for the selected patient.

Select Requested Procedure

In the detailed view the operator has the option to select a dedicated Requested Procedure with the earliest associated Scheduled Procedure Step by clicking on
the Select button of the highlighted Requested Procedure.

Show Patient in main screen

The operator can take over the selected item at any time. The data is stored in the list of “Today”. After all that, the operator can start the examination of the patient and acquire scan data.
The transfer of the selected patient from the “Advanced” – “Scheduled Patients” screen will result in an unscheduled case. The only exception is:
Predefined query keys for Today’s List do match the selected Modality Worklist Item. The Patient is transferred to the main screen. Another MWL default query is triggered by manual or automatic Modality Worklist refresh, and the query results are displayed on Today’s list.

Query conditions for Today’s list is configurable in specific settings→Import Export Settings→Modality Worklist Broad Query.

4.2.1.3.2.2          Proposed Presentation Contexts

Following presentation contexts are offered for each initiated association. During this activity the Application Software uses only

• “Modality Worklist IM – FIND” with Transfer Syntax ILE as SCU

Table 4-7 Proposed Presentation Contexts for Activity Query Modality

Worklist

1Note: C-FIND extended negotiation is offered. Relational-query support is required by the SCP.
2Note : Only acts as SCP when a C-Move-RQ was initiated first and this association is still open.
3Note: CLARUS does not transmit VL Photographic Image IODs via DICOM network. It provides function to DICOM retrieve and import VISUCAM / VISPUPAC VL DICOM VL Photographic Image files from local, external or network drive.
4Note: CLARUS acts as Storage SCU for OP 8 Bit Images generated by CLARUS itself. However, it performs DICOM retrieve and file import only for those OP 8 Bit Images generated by VISUCAM /
VISPUPAC.

4.2.1.3.2.3 SOP Specific Conformance for Modality Worklist SOP Class

Table 4-8 Modality Worklist C-FIND Response Status Handling Behavior

![table 4-8](https://manuals.plus/wp-

content/uploads/2020/12/table-4-8-300x248.jpg)Table 4-9 Attributes involved in Modality Worklist C-FIND request and response

Note 1: If the multicomponent group name representation is enabled the name component group
configured with Priority 1 is shown in the pick list and in the patient’s details. The search string entered in patient’s last name or first name is sent in the alphabetic component group of the attribute (0010,0010) Patient’s Name in the C-Find-RQ (see section 4.4.2.1 for the setting of multicomponent
group names)

Note 2 : Only patient’s first name and last name are displayed in the GUI, but the entire name including
all five components of all three component groups are imported and copied into the storage SOP Instance.
Note 3 : All attributes with grey background are by default excluded from the list of Modality Worklist CFIND-RQ return keys. If needed they can get activated by service personnel.
Note 4 : All attributes with white background are by default included in the Modality Worklist C-FINDRQ as return keys with the exception that sequences are sent zero-length (no sequence items included).

Values of column “Query Keys Matching”:

PBQ

A tag that is marked with PBQ is used as query key in the Patient Based Query mode of the interactive Modality Worklist Query Dialog.

BRQ

A tag that is marked with BRQ is used as query key in the Broad Query mode of the interactive Modality Worklist Query Dialog.

DEF

A tag that is marked with DEF has a value assigned when the interactive Modality Worklist Query Dialog is shown the first time or when the Reset button is pushed. Default values can get modified. The modifications will be stored for next use of Modality Worklist Query Dialog.

DEF*

The default value of the associated attribute can be configured in the Specific settings screen.

RNG

The operator can apply a range as value for the query key.

SEL

The operator can select a value from a given list of values.

Values of column “Query Keys Return”:

X

The tag shall be present in the Modality Worklist C-FIND response. If any required tag is missing the relevant Modality Worklist C-FIND response item (Scheduled Procedure Step) will be ignored and not imported by the application software.

X*

The tag shall be present in the Modality Worklist C-FIND response if its enclosing sequence is present. If any required tag is missing the relevant Modality Worklist C-FIND response item (Scheduled Procedure Step) will be ignored and not imported by the application software.

X1

Either the Scheduled Procedure Step Description (0040,0007) or the Scheduled Protocol Code Sequence (0040,0008) or both shall be present in the Modality Worklist C-FIND response.

X2

Either the Requested Procedure Description (0032,1060) or the Requested Procedure Code Sequence (0032,1064) or both shall be present in the Modality Worklist C-FIND response.

Values of column “Imported”:

X

The value gets imported in the application. Thus this value may have influence in Information Objects which will be created as a result of the performed examination.

Values of column “Displayed”:

PL

Values of this tag are instantly visible in the pick list.

PLD

Values of this tag are visible in the details dialog of the current selected pick list item.

APP

Values of this tag are visible in the application.
Values of column SOP Instance:

X

Values of marked tags will be stored in created SOP Instances. See section 8.1.3 “mapping of attributes” in 8.1.3 Attribute Mapping. Following set of tags can be used as query key in the so called “Patient Based Query”. The Patient Based Query is a working mode of the Modality Worklist Query Dialog.

Table 4-10 Modality Worklist query key details – Patient Based Query

Read User Manual Online (PDF format)

Download This Manual (PDF format)

Download this manual  >>