Measurements and calculations not received

Google Groups archive
1

Hi all, i have setted up a Siemens Acuson Sequoia 512 with orthanc. It seems to work good except for measurements and calculations. Looking at the Acuson user manual it should send calculations using Comprehensive SR SOP Class ( 1.2.840.10008.5.1.4.1.1.88.33), but i only get patients infos and some other tags about machine but not calculations etc. Am i doing something wrong or should i configure something on orthanc?
Thanks all.

2

Hello,

Have you set the “UnknownSopClassAccepted” configuration option of Orthanc to “true”?
https://book.orthanc-server.com/users/configuration.html

If this doesn’t work, please get in touch with the support team of Siemens:
https://book.orthanc-server.com/faq/proprietary.html

Regards,
Sébastien-

3

Hi Sébastien, thanks a lot for your reply. Yes, i have setted it. I did it hoping to get their private tags too but without success.
Have you other tips or suggests before i call siemens?
Thanks

4

Unfortunately, there is nothing I can add, as I don’t have access to a Siemens Acuson system (whereas Siemens has access to Orthanc).

Sébastien-

5

ok, thanks. i will get you updated about that

6

I think i should give a look at “AcceptedTransferSyntaxes” too. The default value is “1.2.840.10008.1.*” and the Comprehensive SR SOP Class is 1.2.840.10008. —>5<— .1.4.1.1.88.33 So this could be the problem. What do you think? I actually am not with the Acuson, i will try tomorrow or Saturday, but a first suggest by you would be nice.
Thanks again

7

Transfer syntax UIDs and SOP class UIDs are two different things:
https://www.dicomlibrary.com/dicom/transfer-syntax/

https://www.dicomlibrary.com/dicom/sop/

Roughly speaking, the transfer syntax UIDs specify how data is encoded, whereas the SOP class UIDs specify what data is encoded.

The “1.2.840.10008.5.1.4.1.1.88.33” SOP class UID is a well-known UID and should be accepted by Orthanc (although I don’t have a sample DICOM file to test this assertion by myself).

All the transfer syntax UIDs start with prefix “1.2.840.10008.1.2”, and I highly doubt Siemens would define its own private transfer syntax, as this would make their modalities incompatible with other vendors.

The only further advice I can give you is to carefully inspect the Orthanc logs in “–verbose --trace-dicom” mode:
https://book.orthanc-server.com/faq/dicom.html

Sébastien-

8

Have you checked that the SR object is actually being sent to Orthanc? I would expect it to be a separate object from any images that are sent, and it might be that you have to configure the settings on the ultrasound unit to send images and reports to Orthanc.

9

I have checked in orthanc explorer and tags are not there. Siemens documentations say that image and SR are sent togheter. Do you have suggest on how can i be sure it is not sent (excluding orthanc explorer) ?

10

Hi all, i have an update.
I have started orthanc with verbose option and tried a transfer.

I will attach now the log. It seems that there is a delimiter problem.

“Parse error in sequence (0040,a170), found (414e,454d) instead of sequence delimiter (fffe,e0dd)”
So maybe the problem is that the measurements are not retrived because it is waiting for “fffe,e0dd” but found “414e,454d”.
Could you please give it a look?
Thanks a lot!

Orthanc.log (42.3 KB)

11

If you don’t provide a sample DICOM file, nobody can give give a look:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

That being said, this error looks like a violation of the DICOM standard by your Siemens modality, for which you should contact the Siemens support team (cf. my first message).

12

You are right. I will contact them now.
Meanwhile i will attach now the dicom file get in orthanc, the log in verbose and trace-dicom mode and the configuration file.
Thanks a lot for your support!

598ebcd6-ecc19a71-e1ee3014-7e5d1079-21eedc45.zip (305 KB)

orthanc.json (32.8 KB)

Orthanc.log (72.7 KB)

13

Unfortunately, as far as I can tell, your ZIP archive was generated by Orthanc, which implies that it does not contain the problematic “Comprehensive SR” DICOM file (there is no occurrence of the “1.2.840.10008.5.1.4.1.1.88.33” string).

You should generate the archive directly on your Siemens modality, as this file cannot be sent to Orthanc.