Service SOP Classes

Module contains implementation of the DICOM service classes. Module also contains useful constants for message statuses and service SOP Class UIDs.

Each service SCU or SCP role is represent by a callable. To define which service SOP Classes are supported by role implementation callable has an attribute sop_classes that lists all SOP Classes. For convenience module provides sop_classes decorator that can be used like this:

@sop_classes([UID1, UID2, UID3])
def sample_scp(asce, ctx, msg):
    pass

This decorator will set (or extend if already exists) sop_classes attribute of decorated function.

Each SCP role implementation must conform to the following interface:

def sample_scp(asce, ctx, msg):
    pass
The arguments have the following meaning:
  • asce - asceprovider.Association object. Can be used to send and receive DIMSE messages, and get access to the Application Entity instance.
  • ctx - presentation context definition (asceprovider.PContextDef). contains context ID for current association, SOP Class UID and selected transfer syntax.
  • msg - received DIMSE message.

Each SCU role implementation must conform to the following interface:

def sample_scu(asce, ctx, *args, **kwargs):
    pass

Arguments have similar meaning to SCP role implementation. First two mandatory arguments are provided by association and the rest are expected from service user.

netdicom2.sopclass.sop_classes(uids)

Simple decorator that adds or extends sop_classes attribute with provided list of UIDs.

netdicom2.sopclass.store_in_file(service)

Sets store_in_file attribute to True

class netdicom2.sopclass.MessageDispatcher

Base class for message dispatcher service.

Class provides method for selecting method based on incoming message type.

get_method(msg)

Gets object’s method based on incoming message type

Parameters:msg – incoming message
class netdicom2.sopclass.MessageDispatcherSCU

Message dispatcher for service class user.

When object instance is called with specific message method type appropriate method is selected and all arguments are forwarded to it.

class netdicom2.sopclass.MessageDispatcherSCP

Messages dispatcher for service class provider.

Object dispatches incoming message to appropriate method.

netdicom2.sopclass.verification_scu(asce, ctx, msg_id)

Sends verification request and returns it’s status result

Parameters:msg_id – message ID
Returns:status in response message. SUCCESS if verification was successfully completed.
netdicom2.sopclass.verification_scp(asce, ctx, msg)

Process received C-ECHO.

Method delegates actual handling of C-ECHO to AE instance by calling its on_receive_echo method and expecting response status from it.

Parameters:msg – incoming C-ECHO message
netdicom2.sopclass.storage_scu(asce, ctx, dataset, msg_id)

Simple storage SCU role implementation.

This implementation provides no SOP Class UIDs. When adding this SCU you should provide list of SOP Class UIDs you want to store.

Parameters:
  • dataset – dataset or filename that should be sent via Storage service
  • msg_id – message identifier
Returns:

status code when dataset is stored.
netdicom2.sopclass.storage_scp(asce, ctx, msg)

Storage SCP role implementation.

Service simple passes file object from received message to on_receive_store method of the application entity. If message handler raises EventHandlingError service response with CANNOT_UNDERSTAND code.

Parameters:msg – received message
netdicom2.sopclass.qr_find_scu(asce, ctx, ds, msg_id)

Query/Retrieve find service user role implementation.

SCU is implemented as generator that yields responses (dataset and status) from remote AE. If status changes from ‘Pending’ generator exits.

Parameters:
  • ds – dataset that is passed to remote AE with C-FIND command
  • msg_id – message identifier
netdicom2.sopclass.qr_find_scp(asce, ctx, msg)

Query/Retrieve find SCP role implementation.

Service calls on_receive_find from AE with received C-FIND parameters and expect generator that would yield dataset responses for C-FIND command.

Parameters:msg – received C-FIND message
netdicom2.sopclass.qr_get_scu(asce, ctx, ds, msg_id)

Query/Retrieve C-GET service implementation.

C-GET service is probably one of the most trickiest service to use. First of all you should remember that C-STORE request messages are received in current association (unlike when you are using C-MOVE), so remember to add proper presentation context for expected object(s). Second, it is strongly recommended to add presentation contexts to your AE with store_in_file set to True, unless you are expecting something small like Structure Report documents. Upon receiving datasets service would call on_receive_store method of parent AE (just like C-MOVE service) and than yield context and dataset. If store_in_file is set to True then dataset is a file object. If not service yields dicom.dataset.Dataset object

Parameters:
  • ds – dataset that contains request parameters.
  • msg_id – message ID
netdicom2.sopclass.qr_move_scu(asce, ctx, ds, dest_ae, msg_id)

Query/Retrieve C-MOVE service implementation.

Service is pretty simple to use. All you have to do is provide C-MOVE request parameters and destination AE. Service will than yield statuses and response messages, that can be used for tracking progress.

Parameters:
  • ds – dataset that contains request parameters.
  • dest_ae – C-MOVE destination
  • msg_id – message ID.
class netdicom2.sopclass.StorageCommitment