/queries/<id>/retrieve response data is inconvenient to parse

Google Groups archive
1

When I make a C-FIND query (/modalities//query) and then look at the response of /queries//answers?expand, I see the following:

[

{
"0008,0005": {
"Name": "SpecificCharacterSet",
"Type": "String",
"Value": "ISO_IR 100"
},
"0008,0052": {
"Name": "QueryRetrieveLevel",
"Type": "String",
"Value": "PATIENT"
},
"0008,0054": {
"Name": "RetrieveAETitle",
"Type": "String",
"Value": "ORTHANC"
},
"0010,0020": {
"Name": "PatientID",
"Type": "String",
"Value": "patient_1"
}
}
]

The response contains both the codings and the human-readable names of the DICOM tags. However, when I call /queries//retrieve, while the actual data in the “Query” field contains the same fields as in /answers?expand, it does not contain the human-readable tag names, but only the codings:

{
"Description": "REST API",
"LocalAet": "ORTHANC",
"Query": [
{
"0008,0052": "PATIENT",
"0010,0020": "patient_1"
}
],
"RemoteAet": "MODALITY_ONE"
}

This is quite inconvenient for API clients because it means that the client must maintain a DICOM dictionary to translate tag codings into their human-readable names.

I would expect the response of /queries//retrieve to look like this:

{
"Description": "REST API",
"LocalAet": "ORTHANC",
"Query": [
"0008,0052": {
"Name": "QueryRetrieveLevel",
"Type": "String",
"Value": "PATIENT"
},
"0010,0020": {
"Name": "PatientID",
"Type": "String",
"Value": "patient_1"
}
],
"RemoteAet": "MODALITY_ONE"
}

I don’t see a reason to not have the response of /retrieve the same as the one of /answers?expand. Is there something I am missing here?

2

You are indeed missing something: Orthanc is free and open-source software you can tune/adapt to your specific use cases, if some feature you would like to have is not implemented (yet).

Learn how to create C++/Python plugins to implement this feature if you need it, then contribute back to the community by sharing your plugin:

https://book.orthanc-server.com/plugins/python.html
https://book.orthanc-server.com/developers/creating-plugins.html

In the future, avoid negative, critical sentences starting with “I don’t see a reason to not have…”: The reason is simply because nobody has asked for this feature before. Remember that Orthanc comes to you at no cost, so please be respectful. The development of free and open-source project is a collaborative process in which the community, including yourself, must take a positive, constructive part:
https://book.orthanc-server.com/contributing.html

Sébastien-

3

Thanks for your response!

Wow… That was the most aggressive response to an innocent question I have ever seen. I was merely trying to understand the reasoning behind having different response formats for what seems to be one and the same data.

I am deeply sorry that "I don’t see a reason to not have…" sounded critical to you. I can assure you that was not intended. I would never ever even think of being critical to an open-source project, for I am an open-source maintainer myself. I am very sorry that my question was perceived as disrespectful.

The question I was asking still stands though. Is there any reason I don’t see to have pretty much one and the same data returned in different formats in /answers?expand and /retrieve? If there is no technical reason, then could these responses be made to have the same format (i.e. to include the DICOM tag names)? This would make it way easier for REST API clients to work with the data returned (i.e. they would not have to maintain their own DICOM dictionary in order to translate DICOM tags’ codings to their names).

Just to add some context, I am asking this question because I am about to implement the C-MOVE API in https://github.com/Ch00k/orthanc-rs, and I am sort of strategizing on how I should do it.

Thank you, and once again I am very sorry for making you think I was critical and disrespectful.

4

Hello,

I apologize for my answer. I really understood you were criticizing my work just for one missing feature. Please excuse what you perceived as aggressiveness from me.

The answer to your last question is: There is no technical reason. That’s just how Orthanc has been working for years, and I never pretended everything is finalized in the REST API of Orthanc. As written in my former answer, there are workarounds for you in the meantime (plugins). I’ll have a look at improving this consistency when time, but beware that such modifications raise a lot of concerns about backward compatibility for other people.

Sébastien-

5

Hi! Thanks for clarification. I certainly understand the backwards compatibility problem related to what I ask.

Now that I look at the response of /queries//retrieve and think of it more, I start wondering if it’s even useful for a client to consume its body, or at least its Query part. I mean, the Query part contains the same information as the /queries//answers?expand after all, so if I ever needed to review the query itself I call the /answers endpoint. I think that the client could safely ignore the entire response body of /queries//retrieve as I see no valuable information in it. The client already knows what their local AET is, and it knows the remote AET it is asking to C-MOVE to.

Again, there is no blame here. I am not implying that your implementation of the response body of the /retrieve endpoint is bad or anything :slight_smile: Just trying to better understand how to implement the C-FIND functionality in my REST API client.

What are your thoughts on this?

P.S. I think the work you are doing with Orthanc is beyond amazing! I could not even start imagining how much harder the life in the company I work for would be if we did not have Orthanc at hand in our R&D process. So thanks a lot for that!

6

Hello,

I have published a changeset related to your request for improvement:
https://hg.orthanc-server.com/orthanc/rev/7826ac059c31

It is now possible to control how the “Query” field in “/queries/{id}/retrieve” is formatted by adding a Boolean field “Full” or “Simplify” in the request body:

$ curl http://localhost:8042/queries/eee56833-cecc-4f2d-b880-9f9c0f139068/retrieve -d ‘{}’
{
“Description” : “REST API”,
“LocalAet” : “ORTHANC”,
“Query” : [
{

[…]

“0008,0052” : “STUDY”,
“0020,000d” : “1.2.840.113543.6.6.4.7.64067529866380271256212683512383713111129”
}
],
“RemoteAet” : “ORTHANC”
}
$ curl http://localhost:8042/queries/eee56833-cecc-4f2d-b880-9f9c0f139068/retrieve -d ‘{“Full”:true}’
{
“Description” : “REST API”,
“LocalAet” : “ORTHANC”,
“Query” : [
{
[…]

“0008,0052” : {
“Name” : “QueryRetrieveLevel”,
“Type” : “String”,
“Value” : “STUDY”
},
“0020,000d” : {
“Name” : “StudyInstanceUID”,
“Type” : “String”,
“Value” : “1.2.840.113543.6.6.4.7.64067529866380271256212683512383713111129”
}
}
],
“RemoteAet” : “ORTHANC”
}
$ curl http://localhost:8042/queries/eee56833-cecc-4f2d-b880-9f9c0f139068/retrieve -d ‘{“Simplify”:true}’
{
“Description” : “REST API”,
“LocalAet” : “ORTHANC”,
“Query” : [
{
[…]

“QueryRetrieveLevel” : “STUDY”,
“StudyInstanceUID” : “1.2.840.113543.6.6.4.7.64067529866380271256212683512383713111129”
}
],
“RemoteAet” : “ORTHANC”
}

The convention of adding the “Full” and “Simplify” fields allows to preserve backwards compatibility with Orthanc <= 1.9.4.

This feature will be part of a future 1.9.5 release. I hope this is what you expected.

Kind Regards,
Sébastien-

1 Like