Help implementing movescu

[willhumphreys4]

Hi,

I wonder if anyone could help me get to the bottom of this running in JupyterLab. The StudyInstanceUID is from a successful CFIND query at the STUDY level using the findscu. The following:

!python -m pynetdicom movescu OurPacsIP&Port -d -S -aet=PYNETDICOM -aec=OurPacsAE -aem=PYNETDICOM -k QueryRetrieveLevel=STUDY -k PatientName=NAME^PATIENT -k StudyInstanceUID=StudyInstanceUID --store -od test

Gives me this output:

The correct SOPInstanceUID is within the Failed SOP Instance UID List

Cheers

[edmcdonagh]

Try including all the tags included in the study study level row of the table in this page: https://www.medicalconnections.co.uk/kb/Query-Parameters They can be empty as long as the study instant UID is there, but they must be present.

…

On Tue, 2 Jan 2024, 18:55 willhumphreys4, ***@***.***> wrote: Hi, I wonder if anyone could help me get to the bottom of this running in JupyterLab. The StudyInstanceUID is from a successful CFIND query at the STUDY level using the findscu. The following: !python -m pynetdicom movescu OurPacsIP&Port -d -S -aet=PYNETDICOM -aec=OurPacsAE -aem=PYNETDICOM -k QueryRetrieveLevel=STUDY -k PatientName=NAME^PATIENT -k StudyInstanceUID=StudyInstanceUID --store -od test Gives me this output: Untitled.png (view on web) <https://github.com/pydicom/pynetdicom/assets/34248362/fc8054b4-b61b-4168-8e4f-ea86fa59b117> The correct SOPInstanceUID is within the Failed SOP Instance UID List Cheers — Reply to this email directly, view it on GitHub <#904>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWABD5YLOV3KN2MFWTHTC3YMRJYZAVCNFSM6AAAAABBKNJRBGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DEOBRGY4TMMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[willhumphreys4]

Hmm unfortunately that gives me the same output - any other thoughts? @scaramallion

[scaramallion]

The failed subops is a little odd (also having 10K subops is a lot, is that how many you expect?). It suggests that it tried to perform the corresponding C-STORE sub-operation but failed, or possibly it's an idiosyncracy of the Move SCP? What's the implementation?

I'd see if the 0xC502 status is mentioned by the Move SCP's docs, or check the log files if you have access to them.

[scaramallion]

You have implemented the C-STORE move destination SCP and registered it with the Move SCP, right? The one with the -aem PYNETDICOM.