2

I'm working on a MPPS SCP as described here: MPPS SCP as a basic framework.

I've been able to test it a bit with DVTk, with some tools that are available here: DVTk

Most of it seems to be working correctly, but the issue I seem to be having is that the response is suppose to have tags with group 0000 returned in the "Command Set" and not in the returned DataSet itself: I actually did set them in the DataSet just to verify that I am getting the correct values, e.g.:

python_mpps_1         | (0000, 0000) Command Group Length  ????
python_mpps_1         | (0000, 0002) Affected SOP Class UID              UI: Modality Performed Procedure Step SOP Class
python_mpps_1         | (0000, 0100) Command Field                       US: 33088
python_mpps_1         | (0000, 0120) Message ID Being Responded To       US: 2
python_mpps_1         | (0000, 0800) Command Data Set Type               US: 0
python_mpps_1         | (0000, 0900) Status                              US: 0
python_mpps_1         | (0008, 0016) SOP Class UID                       UI: Modality Performed Procedure Step SOP Class

I'm not exactly sure what Command Group Length, Command Field and Command Data Set Type should be, but more importantly, I do not know how to set them appropriately. I do not think they should be set in the Dataset, but part of the Command Set object for the N_CREATE response:

#     'N-CREATE-RSP': (
#         'CommandGroupLength', 'AffectedSOPClassUID', 'CommandField',
#         'MessageIDBeingRespondedTo', 'CommandDataSetType', 'Status',
#         'AffectedSOPInstanceUID',
#         'ErrorID', 'ErrorComment'
#     ),

Using DVTk as a testing tool, the MPPS.SCU script in their example scripts, everything seems to work except for the Command Set values not being sent in the response. After a little digging, I think those have to be set in another way, but I am not sure how.

The pynetdicom documentation might have some further info about that (first link), but I've been unable to find it.

SScotti
  • 2,158
  • 4
  • 23
  • 41
  • 1
    Could you post some code that reproduces your problem? pynetdicom should be automatically setting the required command set elements – scaramallion Jul 04 '21 at 22:08

1 Answers1

1

The Command Group Length (0000,0000) is the total number of bytes of your binary encoded message. This should usually be set by the toolkit that you are using (see comment from Scaramillion).

Your command type is an N-CREATE Response, and usually this comes without any dataset. Not knowing the DVT script, I assume that your script does not expect a dataset being attached to the command set.

I.e. SOP Class UID (0008, 0016) should not be present (it is already part of the Command Set as Affected SOP Class UID (0000,0002)), and Command Data Set Type (0000, 0800) should be set to 0x0101 to indicate that no data set is following the command set.

At least this counts for a successful N-CREATE operation.

Amit Joshi
  • 15,448
  • 21
  • 77
  • 141
Markus Sabin
  • 3,916
  • 14
  • 32
  • Thanks. I think pynetdicom takes care of the Command Set as scaramallion said. I'll have to test further, but I'll see. Regarding the response, I actually want to slightly modify the attr_list to add some items that are missing in certain situations. That is because a modality does not support populating all of the desired DICOM tags from the MWL, but I can do that from a MPPS response. I see how to do that, but is that one way in which N_CREATE can be used, to modify the attr_list slightly ? – SScotti Jul 05 '21 at 12:53
  • I'll edit my code further and test again and see what sort of log is produced again in DVTk. I'll have to see if it can capture and log the Command Set. It is a nice package, DVTk, even though it runs on Windows. At least it is free. – SScotti Jul 05 '21 at 12:55
  • 1
    Actually, the N-CREATE is intended for the SCU (Modality) to "announce" attributes to be set in the N-SET message. So I do not see much use of adding/modifying attributes in the N-CREATE Response. The SCU is not expected to react towards that in any way. There is something like "attribute coercion" applicable to the MPPS-SCP, but this does not include sending coerced attributes back to the SCU. That is: For further internal processing, you can do what you want (DICOM does not regulate that), but for communication I would recommend to not send additional attributes back to the SCU – Markus Sabin Jul 05 '21 at 14:25
  • Thanks. That is helpful. Seems like the main purpose of MPPS then is to manage the worklist in knowing when a study is started, and when it is finished, and then I can make modifications to a study after the N_SET message is sent and do some basic housekeeping in terms of managing the worklists ? I am actually already doing something similar on the backend by modifying instances when necessary. – SScotti Jul 05 '21 at 16:41
  • "attribute coercion" is actually what I am interested in, because in some cases some attributes will either be missing (i.e. the RIS or MWL server was down) and the tech might just type in an accession or basic ID, and then the study would have to be "fixed", or as in one case, the modality does not populate the study with tags that are actually in the MWL file. I take it how I "fix" the tags is up to me to handle in the N_SET handler ? – SScotti Jul 05 '21 at 16:44
  • Sounds like N_CREATE and N_SET then are mostly a one-way street ? The modality does not do much with the responses, except for getting a SUCCESS status regarding the information that was sent ? No need to even return the dataset in some cases ? – SScotti Jul 05 '21 at 16:45
  • Exactly. About the usage and purpose of MPPS (and fixing DICOM attributes after imaging is completed), the answer does not fit into the comments section. – Markus Sabin Jul 06 '21 at 06:11