DICOM Adapter

0.7.4

The Clara DICOM adapter is designed for the Clara Deploy SDK. It implements the necessary DICOM services for interoperability between Clara and other medical devices. The Clara DICOM adapter allows receiving and sending of DICOM objects using standard DICOM protocols and interprets standard DICOM part 10 formats.

This container requires Docker 18.09.2 or higher.

Before running the container, use docker pull to ensure an up-to-date image is installed. Once the pull is complete, you can run the container image.

To run Clara DICOM adapter

  1. In the Tags section, locate the container image release that you want to run.

  2. In the PULL TAG column in the table, click the icon to copy the docker pull command.

#. Open a command prompt and paste the pull command. The pulling of the container image begins. Ensure the pull completes successfully before proceeding to the next step. #.

Create an input directory with the following command. That directory will be mounted to the container in subsequent steps.

Copy
Copied!
            

mkdir -p dicom


  1. Create a network for DICOM adapter.

    Copy
    Copied!
                

    docker network create claranet

  2. Configure DICOM adapter. (See the Configuration section.)

  3. Run DICOM adapter with the following commands:

    Copy
    Copied!
                

    docker run -it --rm -d \ --name dicomserver \ --network claranet \ -p 1004:104 \ -v /{path-to-my_config.yaml}:/app/app.yaml \ -v /{path-to-dicom-from-step-4}:/payloads \ dicomserver:<x.x.x> Where:

    • -it keeps STDIN open even if not attached, and allocating a pseudo-TTY

    • –rm deletes the container when finished

    • -d specifies Detached mode: Run containers in the background

    • –name assigns a name to the container, in this case, dicomserver

    • –network connects a container to a network

    • -p publishes container’s port to host (here, we map 1004 on the host to 104 in the container)

    • -v mounts the host folder to container folder

    • <x.x.x&gt; is the container version. For example, 0.1.0.

      Once DICOM adapter is launched, the SCP service will start listening on port 1004 on the host. The SCU service starts monitoring creation of job.done files in the /dicom folder. See the Usages section for details on how to trigger SCU service.

  4. Stop the container and remove the network with the following commands:

    Copy
    Copied!
                

    docker stop dicomserver docker network rm claranet

DICOM adapter configuration (app.yaml) is a YAML formatted configuration file. It contains the following sections:

  • dicom

    • scp: DICOM SCP Service settings

    • scu: DICOM SCU service settings

  • workflow: Workflow mappings

Clara DICOM adapter allows multiple Clara AE Titles to be configured where each AE Title can be mapped to a workflow with one DICOM destination.

Samples

Mapping Clara AE Title to a workflow

The following sample configuration has two workflows configured which accepts DICOM associations from source AE Title DCM4CHEE with IP address 1.2.3.4 (dicom>scp>sources):

ct_ai_workflow

DICOM files that are sent to Clara AE Title NVIDIADGX100 (dicom>scp>ae-titles) in the association are grouped in one single batch. When the association is closed, DICOM adapter triggers the workflow configured which is 0fcdcdea-89c6-456f-b20a-bc7379c54ef2. When the workflow completes, the results are sent to configured destination MyOrthanc.

External DICOM Device C-STORE => NVIDIADGX100 => Workflow (0fcdcdea-89c6-456f-b20a-bc7379c54ef2) => MyOrthanc

mammo_ai_workflow

External DICOM Device C-STORE => NVIDIADGX101 => Workflow (3c9d3b93-86d4-4bc2-b89b-7a12de9f7bda) => PACS

Copy
Copied!
            

dicom: scp: port: 104 ae-titles: - ae-title: NVIDIADGX100 processors: - "Nvidia.Clara.Dicom.Processors.JobProcessor,Nvidia.Clara.DicomServer" - ae-title: NVIDIADGX101 processors: - "Nvidia.Clara.Dicom.Processors.JobProcessor,Nvidia.Clara.DicomServer" max-associations: 2 sources: - host-ip: 1.2.3.4 ae-title: DCM4CHEE scu: ae-title: ClaraSCU max-associations: 2 destinations: - name: MyOrthanc host-ip: 1.2.3.5 port: 104 ae-title: ORTHANC - name: PACS host-ip: 1.2.3.6 port: 104 ae-title: DCM4CHEE workflows: - name: ct_ai_workflow clara-ae-title: NVIDIADGX100 destination-name: MyOrthanc workflow: 0fcdcdea-89c6-456f-b20a-bc7379c54ef2 - name: mammo_ai_workflow clara-ae-title: NVIDIADGX101 destination-name: PACS workflow: 3c9d3b93-86d4-4bc2-b89b-7a12de9f7bda

Grouping DICOM Data by Association

In this sample configuration, DICOM files may be pushed to NVIDIADGX100 in multiple associations as long as all the files are received within the configured timeout value, 300 seconds. When the timeout period has elapsed, Clara DICOM adapter triggers the configured workflow as shown in the above example.

Copy
Copied!
            

dicom: scp: port: 104 ae-titles: - ae-title: NVIDIADGX100 timeout: 300 timeout-group: Association processors: - "Nvidia.Clara.Dicom.Processors.JobProcessor,Nvidia.Clara.DicomServer" ...


Grouping DICOM Data by Patient ID (0010,0020)

This configuration is similar to the sample configuration above. The difference is that received instances are grouped by the Patient ID (0010,0020). This means multiple timers are created; one timer per each distinct Patient ID. If a Patient ID does not receive any new instances within the configured timeout, 300 seconds, a new job is triggered with the configured workflow.

Copy
Copied!
            

dicom: scp: port: 104 ae-titles: - ae-title: NVIDIADGX100 timeout: 300 timeout-group: Patient processors: - "Nvidia.Clara.Dicom.Processors.JobProcessor,Nvidia.Clara.DicomServer" ...

Schema

Copy
Copied!
            

dicom: scp: #DICOM SCP configurations. port: #(int, optional) Default 104. DICOM SCP Port number. ae-titles: #(string[], optional) Default ClaraSCP. - ae-title: ClaraSCP timeout: #(int, optional) Default 0 seconds. Timeout to stop associating incoming DICOM instances to a workflow. If no DICOM instances are received within the specified timeout period, a new workflow request is created for all received DICOM instances. This is useful if multiple DICOM associations are used to transfer the dataset required for a workflow. timeout-group: #(enum: Association, Patient, optional) Default Association. When the timeout value is greater than 0, the SCP service would group instances received based on this setting. Association: groups all instances received within the timeout period. Patient: groups all instances with the same Patient ID (0010,0020) received within the timeout period. overwrite-same-instance: #(bool, optional) Default false. Overwrites existing DICOM instance with the same SOP Instance UID. ignored-sop-classes: #(Optional) List of SOP Class UIDs to ignore and not store on disk. processors: # (string, optional) List of file processors that are executed after association release or timeout. - "Nvidia.Clara.Dicom.Processors.JobProcessor,Nvidia.Clara.DicomServer" #Processor that triggers a job based on the mapped workflow. max-associations: #(int, optional) Default 2. Min: 1, Max:5. Maximum number of simultaneous associations. verification: #(Optional) enabled: #(bool, optional) Default true, Enable C-ECHO. transfer-syntaxes: # (string, optional) List of transfer syntax UIDs supported for Verification SOP class. - [] reject-unknown-sources: #(bool, optional) Default true. Rejects calling AE Titles that are not defined in the source section. log-dimse-datasets: #$(bool, optional) Default false. Gets or sets whether or not to write command and data datasets to log. sources: #(Optional if reject-unknown-sources is false) List of DICOM sources. - host-ip: #(string) IP or host name. ae-title: #(string) AE Title. scu: #DICOM SCU configuration. ae-title: #(string) Clara SCU AE Title. max-associations: #(int, optional) Default 2. Min: 1, Max:5. Maximum number of simultaneous associations. destinations: # (Optional) List of DICOM destinations. - name: #(string) Name of DICOM destination. host-ip: #(string) IP or host name. port: #(int) Port number. ae-title: #(string) AE Title. workflows: - name: #(string) Name of the workflow. clara-ae-title: #(string) A Clara AE Title to associate a workflow with. destination-name: #(string) name of the destination DICOM device configured in scu>destinations. workflow: #(string, optional) Name of the workflow to execute. destination: #(string) Name of the DICOM destination device (configured in dicom>scu>destinations) to output the result to. storage: temporary: ./storage #(string) Path to the temporary storage that is used to store received DICOM instances. payloads: /app/payloads #(string) Path to the workflow payloads storage. output: /app/output #(string) Path to be monitored by the SCU.


DICOM SCP Service

The SCP service accepts standard DICOM C-ECHO and C-STORE commands. please see the DICOM Interface section for more information.

All received instances are saved immediately to the configured temporary storage location storage>temporary. With the default file processor Nvidia.Clara.Dicom.Processors.JobProcessor, all received instances, after timeout elapsed, are moved to the payloads directory storage>payloads after all the files are registered with the Clara Core API.

DICOM instances received are stored on disk as-is using original transfer syntax as described in the DICOM Interface section. User of the Clara Deploy SDK must handle the encoding/decoding of their DICOM files in their container(s). See Third Party Tools for a list of DICOM toolkits available for parsing, encoding or decoding DICOM files.

DICOM SCU Service

This section describes how to trigger DICOM SCU service manually. To implement your own workflow container, you need to write all DICOM results and the job.done flag file using the following file/folder structure:

Copy
Copied!
            

payloads/ |___[job 1]/ |___job.meta # file contains the (UUID/GUID) of the workflow |___output/ # all result files to be pushed to the configured destination |___result1.dcm # DICOM formatted result to be pushed |___result2.dcm # DICOM formatted result to be pushed |___... |___job.done # flag file that is monitored by the SCU service

First, a job folder must be created in the payloads folder. The job folder is created when the SCP service triggers a new job. The job.meta file is also created automatically when a new job is triggered.

Next, your container must put all the DICOM-format output results in the configured output folder. This folder is mapped automatically by Clara.

Finally, create a job.done flag file in the output folder once all results are written. This triggers the Store SCU service to scan the folder for all DICOM formatted files and schedules the files for output to the configured destination.

Please note, DICOM instances are sent as-is, no codec conversion is done as part of the SCU process. See the DICOM Interface section for more information.

The following reference describes the connectivity capabilities of the Clara Deploy SDK out of box. Users implementing the Clara Deploy SDK must update their DICOM Conformance Statement according to their actual application capabilities.

DICOM SCP

Clara DICOM SCP implements C-ECHO and C-Store services to interface with other medical devices, such as PACS. It allows users to define multiple AE Titles to enable DICOM communication and maps each AE Title to a workflow.

DIMSE Services (SCP)

  • C-STORE - accepts incoming DICOM objects

  • C-ECHO - accepts incoming DICOM verification requests

SOP Classes (Transfer) & Transfer Syntax Supported

Clara DICOM SCP accepts any proposed transfer syntaxes and stores any accepted instances as-is on disk without any decoding support. Each AE Title may be configured to ignore and not save certain SOP Classes.

Association Policies

  • Clara DICOM Storage SCP accepts associations but does not initiate associations.

  • Clara DICOM Storage SCP accepts 2 (configurable) simultaneous associations.

  • Asynchronous mode is not supported. All operations are performed synchronously.

  • The Implementation Class UID is 1.3.6.1.4.1.30071.8 and the Implementation Version Name is fo-dicom 4.0.0.

  • Association must be released properly in order for received instances to be associated with a workflow. Files received from an aborted association or an interrupted connection are either removed immediately or removed based on a configured timeout value.

Security Profiles

Clara DICOM Storage SCP does not conform to any defined DICOM Security Profiles. It is assumed that the product is used within a secured environment that uses Firewall, Router Protection, VPN, and/or other network security provisions.

The Clara DICOM Storage SCP service can be configured to check the following DICOM values when determining whether to accept Association Open Requests:

  • Calling AE Title

  • Called AE Title

Clara SCP AE Title can be configured to accept Association Requests from only a limited list of Calling AE Titles.

DICOM SCU

Clara DICOM Storage SCU provides DICOM Storage Service to interface with other medical devices, such as PACS. It is executed at system startup and exists in a container using single configurable AE Title.

DIMSE Services (SCU)

C-STORE - to send processed results that are stored in DICOM format

The Clara DICOM Storage SCU initiates a push of DICOM objects to the Remote DICOM Storage SCP. The system allows multiple remote SCPs to be configured and allows to use configured Remote SCPs in the workflow.

SOP Classes (Transfer) Supported & Transfer Syntax

The DICOM Store SCU service supports all SOP classes of the Storage Service Class. The DICOM Store SCU service transfers a DICOM object as-is using stored Transfer Syntax without the support of compression, decompression or Transfer Syntax Conversion.

Association Policies

  • Clara DICOM Storage SCU initiates associations but does not accept associations.

  • Clara DICOM Storage SCU allows 2 (configurable) SCU instances simultaneously.

  • Asynchronous mode is not supported. All operations are performed synchronously.

  • The Implementation Class UID is 1.3.6.1.4.1.30071.8 and the Implementation Version Name is fo-dicom 4.0.0.

Security Profiles

Not applicable.

Licenses and model files are available. They can be pulled as part of the procedure described above or available in the Clara Deploy SDK. By pulling and using the container, you accept the terms and conditions of these licenses.

Third Party Licenses

For Release Notes, Getting Started Guide and Clara Deploy SDK, please visit the NVIDIA Developer forum at https://developer.nvidia.com/clara. Use the NVIDIA Devtalk forum at https://devtalk.nvidia.com/default/board/362/clara-sdk/ for questions regarding this release.

© Copyright 2018-2019, NVIDIA Corporation. All rights reserved. Last updated on Feb 1, 2023.