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 toTrue
-
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 raisesEventHandlingError
service response withCANNOT_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 toTrue
, unless you are expecting something small like Structure Report documents. Upon receiving datasets service would callon_receive_store
method of parent AE (just like C-MOVE service) and than yield context and dataset. Ifstore_in_file
is set toTrue
then dataset is a file object. If not service yieldsdicom.dataset.Dataset
objectParameters: - 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
-
static
-
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: