Service SOP Classes (sopclass)

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.

pynetdicom2.sopclass.sop_classes(uids)

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

pynetdicom2.sopclass.store_in_file(service)

Sets store_in_file attribute to True

class pynetdicom2.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 pynetdicom2.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 pynetdicom2.sopclass.MessageDispatcherSCP

Messages dispatcher for service class provider.

Object dispatches incoming message to appropriate method.

pynetdicom2.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.
pynetdicom2.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
pynetdicom2.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.

pynetdicom2.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
pynetdicom2.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 the remote AE with C-FIND command
  • msg_id – message identifier
Yield:

response dataset, response status

pynetdicom2.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
pynetdicom2.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
pynetdicom2.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.
Yield:

status and response message

pynetdicom2.sopclass.qr_move_scp(asce, ctx, msg)

Query/Retrieve C-MOVE service implementation.

Service call on_receive_move on AE instance with current presentation context, message dataset and move destination. In response service expects a tuple of remote AE parameters (address, port, etc), number of operation and a generator that would yield datasets to store.

Parameters:
  • asce – active association
  • ctx – presentation context
  • msg – received C-MOVE message
pynetdicom2.sopclass.modality_work_list_scu(asce, ctx, ds, msg_id)

Modality WorkList service implementation (SCU).

Pretty much the same as Query/Retrieve C-FIND

Parameters:
  • asce – active association
  • ctx – presentation context
  • ds – dataset that is passed to the remote AE with C-FIND command
  • msg_id – message ID
Yield:

response dataset, response status

pynetdicom2.sopclass.modality_work_list_scp(asce, ctx, msg)

Modality WorkList service implementation (SCP).

Pretty much the same as Query/Retrieve C-FIND

Parameters:
  • asce – active association
  • ctx – presentation context
  • msg – incoming C-FIND message
class pynetdicom2.sopclass.StorageCommitment

Storage Commitment service implementation.

Handles incoming N-ACTION-RQ and N-EVENT-REPORT-RQ messages.

static n_event_report(asce, ctx, msg)

N-EVENT-REPORT message handler

On incoming N-EVENT-REPORT-RQ message service calls on_commitment_response on the AE instance with provided transaction UID, list of instances stored successfully and list of instances that failed to store.

Parameters:
  • asce – active association
  • ctx – presentation context
  • msg – incoming N-EVENT-REPORT message
static n_action(asce, ctx, msg)

N-ACTION message handler.

On incoming N-ACTION message service call on_commitment_request on the AE instance and expect to get remote AE connection parameters, and two lists of tuples. Each tuple in a list should contain SOP Class UID and SOP Instance UID for each requested instances in the incoming N-ACTION message.

Service would build an N-EVENT-REPORT-RQ message and send it over the new association.

Parameters:
  • asce – active association
  • ctx – presentation context
  • msg – incoming N-ACTION message
pynetdicom2.sopclass.storage_commitment_scu(asce, ctx, transaction_uid, uids, msg_id)

Storage Commitment service implementation (SCU)

Parameters:
  • asce – active association
  • ctx – presentation context
  • transaction_uid – transaction UID
  • uids – tuple of SOP Class UID and SOP Instance UID
  • msg_id – message ID
Returns:

N-ACTION response status

Return type:

statuses.Status