Query Retrieve In Docker

Hi, thank you for building Orthanc, I’ve found it very intuitive to set up and use so far.

I’m running in docker with a postgres backend, I’ve configured a modality representing a remote PACS instances that I want to pull images from, I can create queries, receive responses from the remote PACS and initiate a retrieve, all via the REST API.

So far so good, the API is nice to work with.

I see the retrieve establish on my remote PACS instance and also logged out in the docker logs of my Orthanc instance running on my laptop. I get no errors.

However, I can’t see the retrieved study on the web interface of Orthanc (also running in docker).

Any thoughts on why?

Docker Compose:
version: “2”
services:

first setup through configuration file and build step

orthanc:
build: orthanc
depends_on: [orthanc-index]
restart: unless-stopped
ports: [“4242:4242”, “8042:8042”]
volumes: [“orthanc-storage:/var/lib/orthanc/db:Z”]
environment:
VERBOSE_STARTUP: “true”

orthanc-index:
image: postgres
restart: unless-stopped
ports: [“5432:5432”]
volumes: [“orthanc-index:/var/lib/postgresql/data:Z”]
environment:
POSTGRES_PASSWORD: “postgres”

volumes:
orthanc-storage:
orthanc-index:

orthanc.json:
{
“Name”: “Foo”,
“DicomAet”: “TB_LAPTOP”,
“RemoteAccessAllowed”: true,
“AuthenticationEnabled”: true,
“RegisteredUsers”: {
“orthanc”: “orthanc”
},
“PostgreSQL”: {
“EnableIndex”: true,
“EnableStorage”: false,
“Host”: “orthanc-index”,
“Database”: “postgres”,
“Username”: “postgres”,
“Password”: “postgres”
}
}

Remote modality creation via API:
PUT {{orthanc_host}}/modalities/HEXGBMST1

{
“AET”: “HEXGBMST1”,
“AllowEcho”: true,
“AllowFind”: true,
“AllowFindWorklist”: true,
“AllowGet”: true,
“AllowMove”: true,
“AllowStorageCommitment”: true,
“AllowStore”: true,
“AllowTranscoding”: true,
“Host”: “10.100.43.1”,
“Port”: 5000,
“UseDicomTls”: false
}

Response: 200 OK

C-Find query:
POST: {{orthanc_host}}/modalities/HEXGBMST1/query
Request body:

{
“Level”: “Study”,
“LocalAet”: “TB_LAPTOP”,
“Normalize”: false,
“Query”: { “AccessionNumber” : “REDACTED” },
“Expand”:true,
“Timeout”: 5

}

Response: 200 OK
Response body:
{

“ID”: “578185ad-ad2f-40c5-842c-d20b4c8fc677”,
“Path”: “/queries/578185ad-ad2f-40c5-842c-d20b4c8fc677”
}

Query Request:

POST: {{orthanc_host}}/queries/578185ad-ad2f-40c5-842c-d20b4c8fc677/answers/0/retrieve

Body: TB_LAPTOP

Response: 200 OK
Response body:
{
“Description”: “REST API”,
“LocalAet”: “TB_LAPTOP”,
“Query”: [
{
“0008,0050”: “REDACTED”,
“0008,0052”: “STUDY”,
“0010,0020”: “REDACTED”,
“0020,000d”: “1.2.840.114164.1666628682.2522363023”
}
],
“RemoteAet”: “HEXGBMST1”
}

Log out out from Docker, I’m not sure what the Toolbox.cpp error means, and no further logs are outputted, it doesn’t explicitly say success:
orthanc-orthanc-1 | E1110 11:21:15.807047 Toolbox.cpp:2355] Cannot parse JSON: * Line 1, Column 1
orthanc-orthanc-1 | Syntax error: value, object or array expected.
orthanc-orthanc-1 |
orthanc-orthanc-1 | W1110 11:21:15.809570 OrthancRestModalities.cpp:949] Driving C-Move SCU on remote modality HEXGBMST1 to target modality TB_LAPTOP

I have a successfully completed job in the UI:
Screenshot 2022-11-10 at 11.38.56.png

But still nothing is found when I search of all studies, or search by the accession number I have just retrieved.

Any thoughts? I’m sure it’s a simple config things I’ve missed, but I’ve been going round in circles for a few hours now so figured I would ask this group.

Thank you very much in advance!
Tim

Hi Tim,

The Toolbox error message indicates that the payload of a REST query is invalid → you should check what call is being performed at that time.

However, it seems that the C-Move is triggered and executed correctly. Don’t you see any other logs after that ?

If not, I would assume that your TB_LAPTOP modality is configured to another IP on your remote PACS and therefore, the data is not sent to your Orthanc but somewhere else.

HTH,

Alain

Screenshot 2022-11-10 at 11.38.56.png

Thank you Alain, I think you’re right, I think my remote PACS instance is failing to send the images, or sending them somewhere else.

I am awaiting access to the test PACS server I’m working against so that I can see the complete logs.

I’ve tried issuing the retrieve as a synchronous request, which times out, supporting the suggestion that the images are not getting sent.

However, I’m not sure why the job ends up being considered a success, as the query shows valid data, it knows the images are there, and when I issue a retrieve request it created the expected job, but for some reason the job succeeds. This is more concerning, as there are all kinds of reasons the transfer could fail, and I would expect the job to fail too.

Any thoughts on how to ensure the job fails if the images never arrive?

Thanks!
T

Screenshot 2022-11-10 at 11.38.56.png

Hi Tim,

If you don’t see any tentative connection from the PACS in your verbose logs, I guess that it means that the ORTHANC AET/IP/PORT are not configured correctly on the PACS server or there is a network configuration/firewall that prevents that connection. The PACS is initiating a new connection to Orthanc to perform its C-Store; this is not required for C-Find.

For the MoveScuJob being successful when using asynchronous mode, I guess that, as soon as the PACS accepts the move SCU command, Orthanc assumes that it will execute it correctly.

HTH

Alain.

Screenshot 2022-11-10 at 11.38.56.png

Thank you Alain,

To complete the story, this issue was related to my remote PACS instance being unable to send studies back, and once that was fixed it still wasn’t working, but this ended up being because my nginx config has something wrong with it for the DICOM transfers. I have nginx successfully acting as a reverse proxy and ssl termination for the REST api and web application, but can’t see how I handle the DICOM ports yet. Will look at that another time, unless you have any resources you recommend?

Thanks again for your help, really appreciated.
Tim.

Hi Tim,

Good to know that you are making progress.

We usually do not use nginx to forward the DICOM protocol but this has been documented in this message (but it seems that the resources have moved).
Note that since then, Orthanc now supports DICOM TLS natively.

HTH,

Alain