Empty query results in some Dicom nodes

[salim....@gmail.com]

Hi all,

I have a problem with the Query function of Orthanc.

It happens in 2 different institution with some commercial nuclear medicine workstations.

The problem is that the Query gives empty results in bi-directional way :
If I query the commercial workstation (AW) from orthanc I get empty results.
If I query Orthanc from the commercial workstation I get empty results too.

I tested the query with different workstations and I get some of them with this query problem while others are OK
- For GE : The Xeleris workstation (15 y old version) is OK for Query but the new AWSever failed to Query
- For Philips : The fist version of EBW workstation is OK for query but the next version starting 2010 give also empty query list.

I put in attachment the log results of the both direction query.
I don't see real error message but the list stay empty while I should get patient that met the criteria in both way.

Thanks for your help,

Best regards,

Salim

[Raúl Alexis Betancor Santana]

Seems wear ... if you lookup at the AWS query ... it's looking for PatiendID = *XXXXXXXXX* ... should be empty if you whant all the list.

On the other way, OrthanC querying AWS, you are getting timeout errors, that could means that you have not setup OrthanC on the AWS as a valid modality with query permissions, or ... something very common on the commercial DICOM world ... that they require you to send specific format for the query. I have seen that on ESAOTE Equiptments.

[Salim Kanoun]

Sorry forgot to tell the "XXXXXX" is an anonymization of a real patient ID that should give a result.

Yes, I have looked at AWServer permission and I have checked that my Orthanc is allowed to query.

I think your third idea is probably the good one, it might have some specific rule for that workstation that might be add to Orthanc, I hope that the log will show something to the dev team. 

However I'm ready to do any test needed to find it.

Best regards,

Salim

[Sébastien Jodogne]

Hello,

If I look at your logs, I indeed see that the following query is received by Orthanc:

(0008,0000)  GenericGroupLength = 80

(0008,0005)  SpecificCharacterSet = ISO_IR 192

(0008,0020)  StudyDate = 

(0008,0030)  StudyTime = 

(0008,0050)  AccessionNumber = 

(0008,0052)  QueryRetrieveLevel = STUDY

(0008,0061)  ModalitiesInStudy = 

(0008,1010)  StationName = 

(0008,1030)  StudyDescription = 

(0010,0000)  GenericGroupLength = 52

(0010,0010)  PatientName = 

(0010,0020)  PatientID = *XXXXXXXXX*

(0010,0030)  PatientBirthDate = 

(0010,0032)  PatientBirthTime = 

(0010,0040)  PatientSex = 

(0020,0000)  GenericGroupLength = 24

(0020,000d)  StudyInstanceUID = 

(0020,0010)  StudyID = 

(0020,1208)  NumberOfStudyRelatedInstances = 

Several DICOM "GenericGroupLength" tags are included in the C-FIND query issued by your commercial workstation, but Orthanc <= 1.1.0 didn't support such tags correctly. This has been fixed in Orthanc 1.2.0 by the following changeset:

https://bitbucket.org/sjodogne/orthanc/commits/af60b784d2b8c5143d9e96acae48975a1f32bcf3

As a consequence, which version of Orthanc are you using? Are you certain of using the most recent version (1.2.0)? This can be check by querying the URI "/system".

HTH,

Sébastien-

[salim....@gmail.com]

Yes, i'm certain to run 1.2.0 (It the first and only version I have installed in this computer).

Here my system API :
{
"DatabaseBackendPlugin" : null,
"DatabaseVersion" : 6,
"DicomAet" : "KANOUNIX",
"DicomPort" : 4006,
"HttpPort" : 8042,
"Name" : "MyOrthanc",
"PluginsEnabled" : true,
"StorageAreaPlugin" : null,
"Version" : "1.2.0"

[Sébastien Jodogne]

OK, so I suspect that your DICOM file does not contain some of the DICOM tags as queried by your commercial workstation (they are reproduced in my previous post), which prevents the matching from succeeding.

Use Orthanc Explorer to identify these missing tags.

Afterwards, you can dynamically patch incoming C-FIND requests by providing a Lua script implementing the "IncomingFindRequestFilter()" callback. In your case, your callback would remove all the tags that are missing from your DICOM file. This is explained in the Orthanc Book, with a sample script:

http://book.orthanc-server.com/users/lua.html#callbacks-to-react-to-events

Sébastien-

[salim....@gmail.com]

Correct I don't find

(0008,0052) QueryRetrieveLevel = STUDY => but I guess this one is query specific
(0008,0061) ModalitiesInStudy
(0010,0032) PatientBirthTime

I will try to look at your script but I fear that it may be over my possibilities (i'm a physician, I like the computing side but not so familiar with code writing).

Could these missing tags break the bidirectional query ? Is that something you can fix in a future release ?

Best regards,

Salim

[Sébastien Jodogne]

No, this does not explain your issue.

We cannot provide any further guidance, as your problem is visibly linked either to your network topology, or to the behavior of your proprietary workstations. We would need to be on site to assist you, which is not the case.

Get in touch with your PACS administrator, and with the commercial support of your DICOM modalities. Always remember that you pay your suppliers to assist you in such situations.

As Orthanc is FOSS, your suppliers are able to help you debug its code (we would of course happily fix the issue if they identify a bug within the source code of Orthanc). The converse is not possible: A community project cannot debug a closed-source product.

Sorry,

Sébastien-

[salim....@gmail.com]

Dear Sebastien,

For sure we won't debug the commercial software.
In Dijon they have a good connection with their Philips employee and I will ask to see if he can look at Philips log, but the last time we tried to used Philips log it was so messy that it was unusable.

However, I think that we won't find anything in the log of the commercial software because I obviously see that Orthanc is reciving message.
When I start a very large query (all patients, all date) I see a significant LAN activity and the web page of Orthanc hangs for a long time.
When I run a small query (one patient specific ID) I don't have this huge hang.

I'm pretty sure that Orthanc is receiving something, the LAN activity should come from somewhere and I strongly suspect that data are arriving to Orthanc and maybe the problem is in their processing.

Do you have a deeper log than --verbose to get all messages Orthanc receive from the network ?

Best regards,

Salim

[salim....@gmail.com]

Dear Sebastien,

I wanted to post a new log, I made my very large query in --verbose mode.

You will see that Orthanc is reciving A LOT of answers from AWServer, it recieve 3727 answer messages which is consistent with my number of series in AWserver.
At the end of this very long query : I got my query result in the webpage !

I tried with a smallest request calling one specific ID or a small group of patients (Patient from Today) but here I got nothing and the log only display one answer log

I0120 19:38:29.255957 MongooseServer.cpp:726] GET /queries/2cda873d-12dd-447d-881e-d50b1256d839/answers

So now I know that the communication is OK because I got my very long query (without any conditions) in the result page.
What is broken is specific query, sad because for sure I can't wait to download +3700 results to find my patients.

Anyway, next monday I will try to investigate in GE admin interface to see if I can find more logs but my chance of success are pretty low.

Tell me if this new log give you a new idea about something in your side.

Thanks for your support I really appreciate that.

Best regards,

Salim

[Sébastien Jodogne]

Dear Salim,

That's very interesting: Your last log indicates that the communication between the Orthanc core and your "KANOUNIX" server takes about one second, but that it takes about 100ms to make one query from Orthanc Explorer to the REST API of the Orthanc core (which should be almost immediate). So I feel that you actually face an user interface problem, not a DICOM communication problem.

Have you read the "Orthanc Explorer is slow under Windows on the localhost" item in the FAQ?

http://book.orthanc-server.com/faq/troubleshooting.html

Regards,

Sébastien-

[salim....@gmail.com]

Dear Sebastien,

I tried with 127.0.0.1 and I get the exact same problem.

I made several testing, the only Query that correctly retrieve results is in case of zero filtering (all name/ID/Accession/Studies, all data, all modalities).
If I use any filter (name or ID or Accession or studies, or date or modalities) I get empty result list even for very large request (all patients from 1 year which is almost the entire set of studies in AWserver).

It seems that Orthanc do not speak the same language as AWserver and this is the same behavior with the most recent Philips (EBW) workstations.

I have one questions, when I use no filter I got 3742 answers/content in the log. When I use a filter in only get one line /answers without any number.

Does it mean that Orthanc received an empty result from AWserver ? What is the answer "unit", a matching series ? patient ? or maybe a group of n patients ?

Could it be helpful I can find and show you the DICOM conformance statement of each failing workstation ?

If you have any other idea for testing let me know.

Best regards,

Salim

[salim....@gmail.com]

Dear Sebastien,

I'm a bit lucky because in my departement I found a station for which the Query is OK (with filter, fully OK).

I attached the conformance statement of both workstations :
- GE Xeleris 3.1 with the Query OK
- GE AWServer 3.2 with the Query broken (except if no conditions is used).

I might picked up something interesting :
Xeleris 3.1 support both Patient Root and Study Root query model while AWServer 3.2 only support the Study root query model.

May I found something interesting here ?

Best regards,

Salim

[Sébastien Jodogne]

When you write "I tried with 127.0.0.1 and I get the exact same problem":

• Have you tried the other part of the FAQ (disable IPv6)?
• Which problem are you referring to? Doing C-FIND from Orthanc to GE modalities, or doing C-FIND from GE modalities to Orthanc? Is it a slowness problem in Orthanc Explorer (your logs indicate 10 minutes to display the 3742 answers), or is it a general communication problem? You are mixing several issues, and I cannot follow you anymore. Please clearly separate the concerns, and structure your posts.

As mentionned in its DICOM conformance statement, Orthanc supports both Patient Root and Study Root models, both as SCU and as SCP, so this is totally unrelated:

https://bitbucket.org/sjodogne/orthanc/src/default/Resources/DicomConformanceStatement.txt

From my point of view, the fact that you don't see results when querying GE from Orthanc results from the fact that your commercial modality does not support the wildcards introduced by Orthanc in its C-FIND query in the ("Study Date" fields). This is exactly the purpose of the fourth argument in the "DicomModalities" configuration of options: Have you played with the latter argument?

http://book.orthanc-server.com/users/configuration.html

Once again, get in touch with your commercial support. Only they can help you identifying what is wrong with your setup (notably in the wildcards mentioned above). I cannot do reverse engineering in their behalf, especially from a remote location.

Final word: Don't forget you are not the only Orthanc user, and that my bandwidth is limited. The time I spent with you debugging something that you commercial suppliers could debug (and for which you pay maintenance fees), is time I cannot spent on the core of Orthanc, which freezes new features and penalizes the entire Orthanc community.

Regards,

Sébastien-

[salim....@gmail.com]

Le lundi 23 janvier 2017 10:22:41 UTC+1, Sébastien Jodogne a écrit :
> When you write "I tried with 127.0.0.1 and I get the exact same problem":

> Have you tried the other part of the FAQ (disable IPv6)?Which problem are you referring to? Doing C-FIND from Orthanc to GE modalities, or doing C-FIND from GE modalities to Orthanc? Is it a slowness problem in Orthanc Explorer (your logs indicate 10 minutes to display the 3742 answers), or is it a general communication problem? You are mixing several issues, and I cannot follow you anymore. Please clearly separate the concerns, and structure your posts.

Dear Sebastien

Yes i'm only using IPv4, IPv6 has been always disabled.

The problem i'm talking about is doing a C-Find from Orthanc To GE AWSever. It is not a slowness problem, it is a "empty result" problem. I get answer only if I use none filter, that is why I got 3742 results but if I use any filter I always get an empty result page (while I know that AWServer contains study that should match the filter).

The reverse problem about doing C-Find from AwServer to Orthanc also exist and gives me empty results for each query but I stay focus on the first direction (Orthanc to AWServer).

I have tried all the manufacturer patches in the fourth argument none of them allowed me to get my query results.

I will try to see if I can get support from either GE in Toulouse or Philips in Dijon.

Best regards,

Salim


> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > Salim

[Sébastien Jodogne]

Hello,

 

Yes i'm only using IPv4, IPv6 has been always disabled.

The problem i'm talking about is doing a C-Find from Orthanc To GE AWSever. It is not a slowness problem, it is a "empty result" problem. I get answer only if I use none filter, that is why I got 3742 results but if I use any filter I always get an empty result page (while I know that AWServer contains study that should match the filter).

The reverse problem about doing C-Find from AwServer to Orthanc also exist and gives me empty results for each query but I stay focus on the first direction (Orthanc to AWServer).

I have tried all the manufacturer patches in the fourth argument none of them allowed me to get my query results.

I will try to see if I can get support from either GE in Toulouse or Philips in Dijon.

Fine, thanks for reexplaining, the immediate issue now sounds much clearer to me.

I confirm this is most probably a problem with the way Orthanc formats its C-FIND query against your GE modalities. It should be handled by introducing a new "fourth argument" dedicated to GE modalities, but we need the help of your GE support to understand what should be done.

In the meantime, you can dynamically alter the C-FIND queries generated by Orthanc through the "OutgoingFindRequestFilter()" Lua callback, that is described in the Orthanc Book:

http://book.orthanc-server.com/users/lua.html#fixing-c-find-requests

This Lua callback will help the GE support and yourself to experiment what patch should be implemented by the "fourth argument for GE". Please share your findings here, so that we can bring the patch to the Orthanc core.

Regards,

Sébastien-

[salim....@gmail.com]

Hi sebastien,

Actually your Lua script that replace the '*' by ' ' is solving the query from Orthanc to AWServer. Now the Query is working properly.

function OutgoingFindRequestFilter(query, modality)
for key, value in pairs(query) do
if value == '*' then
query[key] = ''
end
end

return query
end

So It should allow you to patch AWserver specific syntax.
Is the '*'=> ' ' is one of the predifined manufacturer option ? Because I tried them all and never get the Query working with none of them.

I'm trying to play with the opposite direction AWS=> Orthanc to see if I can find a patch as well

Best regards,

Salim

[Chico Venancio]

Salim,

All the problematic queries were from Orthanc Explorer?

Chico Venancio 

(98) 9 8800 2743

CEO - VM TECH 

[salim....@gmail.com]

Yes, I use only Orthanc Explorer for now,

Best regards,

Salim

[Chico Venancio]

Then the "bug" is the same as https://bitbucket.org/sjodogne/orthanc/issues/19/query-retrieve-wildcard-problems. That lua script will solve it.

Chico Venancio 

(98) 9 8800 2743

CEO - VM TECH 

[Salim Kanoun]

OK,

I there a way you could include this "script change" to a vendor specific option ? 

The problem I have is that we try to build a connection between orthanc and our homemade PET/CT viewer. So I'm going to teach physician in a setup guide how to install Orthanc to get all Orthanc's features along with our PET/CT viewer in Fiji. It is a bit complicated to teach them to install a Lua script.

I'm going to try to see if it is the same "*" problem for the Philips workstation in Dijon (but since i'm 600 km away it is much harder). 

That way I could tell you if it is something applicable to Philips manufacturer too.

Best regards,

Salim

[salim....@gmail.com]

Hi Sebastien, Hi all,

I'm happy to post here my final solution, now I have bi-directionnal query working for both GE (Xeleris and AWserver) and Philips (the 2 versions of the ADW workstation).

I made 2 Lua scripts, 1 for the ORTHANC=>Commercial station query and 1 other for the Commercial station => ORTHANC query.
These 2 scripts fix both GE and Philips.
I hope this will allow you to add the specific vendor tag for the next versions of Orthanc.

- To fix the Query from Orthanc to GE/Philips, I used the previously posted script here (https://groups.google.com/d/msg/orthanc-users/3g7V7kqr3g0/3Aiu86CnDwAJ) to replace the '*' by ''

function OutgoingFindRequestFilter(query, modality)
for key, value in pairs(query) do
if value == '*' then
query[key] = ''
end
end

return query
end

- To fix the query from GE/Philips to ORTHANC, I had to erase 3 tags as follow :

function IncomingFindRequestFilter(query, origin)
-- First display the content of the C-Find query
PrintRecursive(query)
PrintRecursive(origin)

-- Remove the "PrivateCreator" tag from the query
local v = query
-- generic group lenght
v['0008,0000'] = nil
v['0010,0000'] = nil
v['0020,0000'] = nil
return v

end

(a similar issue was posted here for Efilm https://groups.google.com/d/msg/orthanc-users/qlsYdf8NOH4/s7qCgWtQDAAJ)

I put in attachment the log of the query (GE AWserver, Xeleris and Philips to Orthanc) of each manufacturer.

I hope my experience could allow to enhance the query compatibility of this software that I appreciate so much.

Best regards,

Salim

[Alain Mazy]

Hi Salim,

Thanks for sharing this information.

Concerning the IncomingFindRequestFilter(), it seems that your proposal is very close to what has been done in this commit: https://bitbucket.org/sjodogne/orthanc/commits/af60b784d2b8c5143d9e96acae48975a1f32bcf3 that has been included in v1.2.0.  

What version are you using ?  If you are using an older version.  That would be great if you could test with v1.2.0 (and without your IncomingFindRequestFilter callback).

Best regards,

Alain.

--

Alain Mazy / CTO 
a...@osimis.io / +32 494 31 67 27

	OSIMIS S.A.  Rue bois Saint-Jean 15/1BE-4102 Seraing  www.osimis.io

[Salim Kanoun]

Dear Alain,

I'm sure to run 1.2.0 as you can verify in my /system API I posted in the previous responses. 

I can guarantee that those tag are still blocking the queries, tell me if you need additional experiences/logs, to debug.

Best regards,

Salim

[Alain Mazy]

Dear Salim,

Sorry, the patch I pointed you on was used only in the ModalityWorklist plugin, not in the standard C-Find.  

I think we may ignore the group-length tags in any case.  I'll check with Sebastien if we should apply this to all modalities (it does not make much sense to compare length in queries with length in dicom files).

Note that these 3 length tags are already ignored for "eFilm2" modalities.  If we don't ignore all group-length, we'll introduce new modality types for yours.

About the outgoing requests, there is already this kind of hack for the "AgfaImpax" modality.  Can you check it works if you define your modality as "AgfaImpax" ?  

Can you give us the exact name of your Philips modality ?  "Philips" might be too generic for the configuration file.

Thanks for your help.

Alain.

[salim....@gmail.com]

Dear Alain,

The Efilm2 option correctly fix the incoming requests (GE to Orthanc)

But the AgfaImpax do not fix the outgoing request (Orthanc to GE).
If I refer to this post (https://groups.google.com/d/msg/orthanc-users/_Tw7J8s31Ho/vXIMiGDfdxoJ) the '*' erase was discussed patient birth date while my script replaced all the '*' by '' (for all tags). Maybe that is why this AgfaImpax is still not solving my queries ?

For Philips, it is "ADW" workstation
For GE, the patches fix both "Xeleris" which is GE software for conventional scintigraphy and "AWServer" which is the newer server application provided by GE which merge many post-processing software (PET/CT, CT and probably MRI).

Don't hesitate if you need more data, it is a pleasure to contribute.

Best regards,

Salim

> OSIMIS S.A. 
> Rue bois Saint-Jean 15/1BE-4102 Seraing 
> www.osimis.io
>  
>
>
>
>
>
>
>
>
>
>

> --
>
>
>
>
>
>
>
>
> Alain Mazy / CTO 
> a...@osimis.io / +32 494 31 67 27
>

[Alain Mazy]

Hi Salim,

Thanks for your tests.  I think we have all info to update Orthanc with new modality types.  I'll keep you updated once it's done.

Best regards,

Alain.

OSIMIS S.A.  Rue bois Saint-Jean 15/1BE-4102 Seraing  www.osimis.io

[abid halim]

Hello , I have a problem, I cannot restore images stored in orthanc to AWServer But I can recover it using console mri or ct

[Sébastien Jodogne]

The latest post from Halim is by no way related to the present thread. As a consequence, I'm now forced to lock this thread.

Halim, please start a new thread to discuss your issues, and avoid to disturb other threads in the future:

https://book.orthanc-server.com/users/support.html

On Sunday, December 26, 2021 at 9:32:42 AM UTC+1 halim...@gmail.com wrote:

Hello  I have a problem, I cannot restore images stored in orthanc to AWServer But I can recover it using console mri or ct