Problem to get worklist working with Siemens C-Bogen

Google Groups archive
1

Hi,

just sitting together with a technician trying to connect an xray (C-Bogen, Siemens) to Orthanc 1.2.
C-Store works but modality does not show the worklist entry that Orthanc delivers.

As the log shows, the C-FIND is received but the Orthanc log does not indicate if something was delivered or if there is no match. And if there is no match, I am wondering why?

here ist the Orthanc log in --trace mode

Jun 21 14:19:44 JBYQJG2 orthanc: T0621 14:19:44.211398 OrthancPlugins.cpp:2849] Calling service 7003 from plugin /usr/share/orthanc/plugins/libModalityWorklists.so
Jun 21 14:19:44 JBYQJG2 orthanc: T0621 14:19:44.212375 OrthancPlugins.cpp:2849] Calling service 21 from plugin /usr/share/orthanc/plugins/libModalityWorklists.so
Jun 21 14:19:44 JBYQJG2 orthanc: I0621 14:19:44.212513 PluginsManager.cpp:171] Received worklist query from remote modality SMCOMPACT1:
Jun 21 14:19:44 JBYQJG2 orthanc: {
Jun 21 14:19:44 JBYQJG2 orthanc: “0008,0050” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0008,0090” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0008,1110” : [],
Jun 21 14:19:44 JBYQJG2 orthanc: “0010,0010” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0010,0020” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0010,0030” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0010,0040” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0020,000d” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0032,1060” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0032,1064” : [],
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0100” : [
Jun 21 14:19:44 JBYQJG2 orthanc: {
Jun 21 14:19:44 JBYQJG2 orthanc: “0008,0060” : “XA”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0001” : “SMCOMPACT1”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0002” : “20170621”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0003” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0004” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0005” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0006” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0007” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0009” : “”,
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,0010” : “SMCOMPACT1”
Jun 21 14:19:44 JBYQJG2 orthanc: }
Jun 21 14:19:44 JBYQJG2 orthanc: ],
Jun 21 14:19:44 JBYQJG2 orthanc: “0040,1001” : “”
Jun 21 14:19:44 JBYQJG2 orthanc: }
Jun 21 14:19:44 JBYQJG2 orthanc:
Jun 21 14:19:44 JBYQJG2 orthanc: T0621 14:19:44.212546 OrthancPlugins.cpp:2849] Calling service 15 from plugin /usr/share/orthanc/plugins/libModalityWorklists.so
Jun 21 14:19:44 JBYQJG2 orthanc: T0621 14:19:44.212565 OrthancPlugins.cpp:2849] Calling service 7002 from plugin /usr/share/orthanc/plugins/libModalityWorklists.so
Jun 21 14:19:44 JBYQJG2 orthanc: I0621 14:19:44.218146 CommandDispatcher.cpp:891] DUL Peer Requested Release
Jun 21 14:19:44 JBYQJG2 orthanc: I0621 14:19:44.218156 CommandDispatcher.cpp:898] Association Release

the modality station name and AET is SMCOMPACT1

the worklist entry that Orthanc shall deliver is this here

[root@JBYQJG2 worklists]# dcmdump worklist_JPRtRvR7-NW_00u5YdEt3Qn20H9_BPpV1498047231.wl

Dicom-File-Format

Dicom-Meta-Information-Header

Used TransferSyntax: Little Endian Explicit

(0002,0000) UL 200 # 4, 1 FileMetaInformationGroupLength

(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion

(0002,0002) UI [1.2.276.0.7230010.3.1.0.1] # 26, 1 MediaStorageSOPClassUID

(0002,0003) UI [1.2.276.0.7230010.3.1.4.8323328.10133.1498047231.588847] # 56, 1 MediaStorageSOPInstanceUID

(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID

(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.0] # 28, 1 ImplementationClassUID

(0002,0013) SH [OFFIS_DCMTK_360] # 16, 1 ImplementationVersionName

Dicom-Data-Set

Used TransferSyntax: Little Endian Explicit

(0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet

(0008,0050) SH [45] # 2, 1 AccessionNumber

(0010,0010) PN [TEST^INGO] # 10, 1 PatientName

(0010,0020) LO [080285] # 6, 1 PatientID

(0010,0030) DA [19700101] # 8, 1 PatientBirthDate

(0010,0040) CS [M] # 2, 1 PatientSex

(0040,0100) SQ (Sequence with explicit length #=1) # 52, 1 ScheduledProcedureStepSequence

(fffe,e000) na (Item with explicit length #=3) # 44, 1 Item

(0008,0060) CS [XA] # 2, 1 Modality

(0008,1010) SH [SMCOMPACT1] # 10, 1 StationName

(0040,0002) DA [20170621] # 8, 1 ScheduledProcedureStepStartDate

(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem

(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem

[root@JBYQJG2 worklists]#

quick response would be great, because we are at a customer right now

best

Torsten

2

Hi Torsten

At very first look, I would suggest that the tag “0040,0010” : “SMCOMPACT1” is present in your request but not in your worklist file. I would eventually try to add a small lua script to remove this tag from the query. An example of such a script can be found here:
http://book.orthanc-server.com/plugins/worklists-plugin.html#common-problems

.
For the future, to help people debugging this kind of problems, I have added some extra logs in the Modality Worklist plugin: https://bitbucket.org/sjodogne/orthanc/commits/89d17c72287b70b8f1e69a5f4004df056feb8c45

It will add a log like:

I0623 16:41:57.583462 PluginsManager.cpp:172] Worklist C-Find: parsed 1 files, found 0 match(es)

I hope this might help you in the future.

Br,

Alain.

3

Thank you Alain!

Filtering the two tags “0040,0001” and “0040,0010” out with LUA sounds like the right way to solve it.

Although I am not sure what all the other empty values in the query do mean in terms of matching.
Does the worklist entry have to have these empty values as well to match?
Do you have a description how matching works for the worklist plugin?

As this is quite a common problem (query does not match to provided worklist entries), I suggest to add a special mode to the worklist plugin.
In this mode, user could set the tags used for matching while all other attributes a modality sends would simply be ignored.
This would make integration much easier. E.g. one could set only modality type as relevant for matching.

BR
Torsten

4

Thank you Alain!

Filtering the two tags "0040,0001" and "0040,0010" out with LUA sounds
like the right way to solve it.

Although I am not sure what all the other empty values in the query do
mean in terms of matching.
Does the worklist entry have to have these empty values as well to match?

All the empty values in the C-Find are there to list the dicom tags that
shall be returned in the response. This is the standard way to do it in
Dicom.

Do you have a description how matching works for the worklist plugin?

No. I think the way matching works is quite standard but I'll try to add a
note in the orthanc-book to explain it with a sample (your problem is a
good one to explain how it works).

As this is quite a common problem (query does not match to provided
worklist entries), I suggest to add a special mode to the worklist plugin.
In this mode, user could set the tags used for matching while all other
attributes a modality sends would simply be ignored.
This would make integration much easier. E.g. one could set only modality
type as relevant for matching.

I understand your point. Indeed, that could ease integration. However, we
usually favor standard implementations to 'hacks'. We don't want Orthanc
to become as hackish as some other proprietary softwares. So we'll first
try to improve the documentation and reference to Lua scripts to customize
C-Find requests.
BTW, these lua scripts are already a hack to fix a problem that should
ideally be solved either in the tool that generates the worklist or, in the
modality making the C-Find requests.

Hope you understand my point of view.

Best regards

Alain.