C.4 Networking
Prev | C Conformance Statement Sample DICOMRis Interface (Informative) | Next

## C.4 Networking

### C.4.1 Implementation Model

#### C.4.1.1 Application Data Flow

Figure C.4.1-1. DICOM Standard Interface

The DICOMRis DICOMSRV application provides access to Scheduled Procedure information, supports updating of the RIS database as procedures are performed. The various flows in the diagram above are described as follows

DICOMSRV accepts associations for Verification from Verification SCUs and responds automatically with Success status

DICOMSRV accepts Association Requests for Modality Worklist from MWL SCUs and responds to queries from these SCUs. When a query is received DICOMSRV engages in local real-world activity Scheduled Procedure Queries. This results in a set of matching responses that DICOMSRV returns to the MWL SCU.

DICOMSRV accepts Association Requests for Modality Performed Procedure Step from MPPS SCUs and responds to N-CREATE and N-SET Requests from these SCUs. When an N-CREATE or N-SET is received DICOMSRV engages in local real-world activity Update Procedure. This results in updates to the DICOMRis Database per the contents of the received message. DICOMSRV then returns N-SET or N-CREATE status to the MPPS SCU.

#### C.4.1.2 Functional Definition of AEs

##### C.4.1.2.1 Functional Definition of DICOMSRV Application Entity

DICOMSRV is a background process running on a Unix server. A single instance of DICOMSRV is started at System boot but multiple instances may be running at any one time as a result of forking of additional processes. The application may be started/restarted interactively via a utility. In addition, there is a monitoring process that may be configured to restart the application automatically should it crash. Events are logged to application-specific log files with a time stamp. Multiple logging levels are supported. At the lowest logging level the following are logged:

- The AE Title of the remote AE when the Association is created

- The status of each DICOM Service Request

- Any updates to the DICOMRis Database

Higher levels of logging can be configured to cause dumping of the contents of DICOM Service and Association messages..

DICOMSRV will listen for connection requests at the Presentation Address configured for its AE Title. This application is an implementation of a concurrent server; it forks a new process for each connection request it receives. Each forked process exists for the life of a single association and then exits. DICOMSRV will accept Presentation Contexts for the Modality Worklist, Modality Performed Procedure Step and Verification SOP Classes. Validation of DICOM Service Request messages is configurable using command-line parameters and may return Failure status in the event of an invalid Service Request according to the specifications in the standard. Upon receipt of a Verification Request DICOMSRV will respond with a successful Verification response. When a MWL query is received DICOMSRV will query the DICOMRis database for a list of Scheduled Procedure Steps matching the query and will return a pending C-Find response for each match. Before DICOMRis can include patient and order information in response to a Modality Worklist query, patients must be registered and there must be orders for those patients in the DICOMRis database.. Registration and order information is typically interfaced to DICOMRis from a HIS but can also be entered directly into DICOMRis using DICOMRis's registration and order entry applications. Reception of an MPPS N-Create or N-Set Request may result in updates to various tables in the DICOMRis database and may result in changes to the procedure state of the Requested Procedure(s) referenced within the message. If an MPPS message containing non-matching demographic data is received, this will be logged, an exception document generated and an entry added to an exception table in the database.

#### C.4.1.3 Sequencing of Real World Activities

Figure C.4.1-2. Sequencing Constraints

Under normal circumstances the sequencing depicted above applies:

1. The Modality queries for a worklist of Scheduled Procedure Steps

2. DICOMSRV searches its database and returns matches to the query

3. The Modality begins performance of a Procedure Step and sends the MPPS N-CREATE

4. The Modality completes or discontinues the procedure and sends the MPPS N-SET with status of COMPLETE or DISCONTINUED

The workflow above is not the only one possible. For example, in a Trauma or unscheduled flow there may be no worklist query prior to the performance of the procedure and the sending of MPPS messages. The flow would also be altered if the Modality did not support both Modality Worklist and MPPS. The Description and Sequencing of Activities and the SOP Specific Conformance sections below for the respective Real World Activities provide additional detail

Prev | Up | Next
C.3.4 Additional Remarks and Definitions for This Example | Home | C.4.2 AE Specifications