4.1.1. Application Data Flow

The core component of dcm4che DICOM Archive 5 is a Java Enterprise Application deployed in WildFly AS, which provides DICOM services over the DICOM Upper Layer protocol (DUL) and HTTP, HL7 v2 services over the Minimal Lower Layer Protocol (MLLP), various proprietary RESTful services and a Web UI accessable by HTML 5 compliant web browsers.

It uses any LDAP v3 compatible LDAP server as configuration backend and a relational database for supporting query and data management services.

The received DICOM objects are not stored in the database, but in a separated storage backend - typically any type of file system, but also cloud storage supported by Apache jclouds may be used as storage backend.

System-log and audit messages may be stored into the Elastic Stack.

RESTful services and the Web UI may be secured with OpenID Connect using Keycloak as Authentication Server.

../../_images/components.svg

Fig. 4.1 System components

System components may be distributed over multiple hosts, as multiple instances of the Archive Application may share one LDAP server and one database.

../../_images/multihost-deployment.svg

Fig. 4.2 Multi-host deployment

System components of dcm4che DICOM Archive 5 are also available as Docker images to run within Docker containers.

../../_images/docker-deployment.svg

Fig. 4.3 Docker deployment

Conceptually the network services may be modeled as the following separate AEs, though they may share one AE Title, or one AE may have multiple instances identified by different AE Titles, with different configuration.

  • Storage Application Entity, which receives incoming images and other Composite Object Instances and accepts requests for commitment for the safekeeping of the received objects.

  • Query/Retrieve Application Entity, which processes queries for Patient, Study, Series, and Instance information and also processes retrieval requests, sending the requested objects to the retrieve destination AE.

  • Workflow Application Entity, which processes queries for Scheduled Procedure Steps, receives Performed Procedure Step messages and optionally forwards them to any remote AE, and also notifies remote AEs about the availability of received instances.

  • STOW-RS, which receives DICOM Objects or metadata with bulkdata via HTTP POST requests.

  • QIDO-RS, which provides access to Patient, Study, Series, and Instance data of received objects via HTTP GET requests.

  • WADO-URI, which provides access to individual DICOM Objects - as DICOM file or rendered to non-DICOM media types for display - via HTTP GET requests.

  • WADO-RS, which provides access to the metadata, the bulk data or the whole DICOM Objects, of a whole Study or Series or an individual object via HTTP GET requests.

  • WADO-WS, which provides access to DICOM Objects - as DICOM file or rendered to non-DICOM media types for display - via SOAP HTTP Requests.

../../_images/application-data-flow-diagram.svg

Fig. 4.4 Application Data Flow Diagram

../../_images/wrkflw-application-data-flow-diagram.svg

Fig. 4.5 Workflow Application Data Flow Diagram

../../_images/stow-application-data-flow-diagram.svg

Fig. 4.6 Web Storage Application Data Flow Diagram

../../_images/wado-application-data-flow-diagram.svg

Fig. 4.7 Web Access Application Data Flow Diagram