Auto-routing by CalledAETitle, equivalent tag when using an Orthanc peer?

I am assisting a mobile rad practice with an Orthanc setup to replace their current proprietary DICOM relay arrangement.

The intention:
The tech chooses either the normal DICOM destination, or an alternate destination within the modality or modality software.

The local, mobile Orthanc instance then connects back to a central Orthanc instance over a cellular connection and sends the study only once.

The central Orthanc instance sends copies to the PACS or to multiple PACS based on the choice the technician made in the beginning.

Currently:
By pointing the DICOM destinations at Orthanc and setting different AE Titles, I was able to set up auto-routing with a LUA script on the laptop to accomplish this if I’m using direct DICOM to transmit from the laptop to the central instance.

However, when I switch to using SendToPeer instead of SendToModality, naturally routing by CalledAETitle breaks. So then I started looking at modifying the study, using some random DICOM tag to carry that information forward across the peer connection.

That’s not working out so well, likely due to my poor coding skills. :smiley:
“LuaScripting.cpp:772] Error while processing Lua events: Bad request”

What I’m hoping, is that there’s a simpler solution, something equivalent to the CalledAETitle that would apply when using a peer connection.

A tag like CalledPeerName or something, where I can have two peers in the config pointing at the same URL, but with different names.

Is there anything like that?

Scripts for reference only:

LUA on laptops:

function OnStoredInstance(instanceId, tags, metadata, origin)
print(‘DICOM Routing Started’)
– Extract the value of the “CalledAet” DICOM tag
local CalledAETVar = string.upper(origin[‘CalledAet’])

if string.find(CalledAETVar, ‘PACS_B’) ~= nil then
– Send PACS_B studies to PACS_ROUTE_B.
print(‘Called AE Title is PACS_B’)
print(‘Forwarding to PACS_ROUTE_B’)
Delete(SendToPeer(instanceId, ‘PACS_ROUTE_B’))
print(‘Sent to PACS_ROUTE_B, Study Deleted’)
end

if string.find(CalledAETVar, ‘PACS_A’) ~= nil then
– Send PACS_A studies to PACS_ROUTE_A.
print(‘Called AE Title is PACS_A’)
print(‘Forwarding to PACS_ROUTE_A’)
Delete(SendToPeer(instanceId, ‘PACS_ROUTE_A’))
print(‘Sent to PACS_ROUTE_A, Study Deleted’)
end

print(‘DICOM Routing Complete’)
end

LUA on central server:

function OnStoredInstance(instanceId, tags, metadata, origin)
print(‘DICOM Routing Started’)
– Extract the value of the “CalledAet” DICOM tag
local CalledAETVar = string.upper(origin[‘CalledAet’])

if string.find(CalledAETVar, ‘PACS_ROUTE_A’) ~= nil then
– Send PACS_ROUTE_A studies to both Client A and our PACS.
print(‘CalledAETVar is PACS_ROUTE_A’)
print(‘Forwarding to Client A’)
SendToModality(instanceId, ‘CLIENT_A_PACS’)
print(‘Sent to Client A’)
print(‘Sending to our PACS’)
Delete(SendToModality(instanceId, ‘MOBILE_PACS’))
print(‘Sent to our PACS, Study Deleted’)
end

if string.find(CalledAETVar, ‘PACS_ROUTE_B’) ~= nil then
– Send MOBILE_PACS studies to our PACS.
print(‘Sending to Mobile PACS’)
Delete(SendToModality(instanceId, ‘MOBILE_PACS’))
print(‘Sent to our PACS, Study Deleted’)
end

print(‘DICOM Routing Complete’)
end

First, consider the following Lua script:

function OnStoredInstance(instanceId, tags, metadata, origin)
PrintRecursive(origin)
end

Secondly, send an image to Orthanc through its REST API (i.e. using the “Orthanc peer” mechanism), using an HTTP user that is declared in the “RegisteredUsers” configuration option (in this case, the user is “alice” with password “orthanctest”):

$ curl http://localhost:8042/instances --data-binary @/tmp/sample.dcm -H ‘Expect:’ -u alice:orthanctest

Then, here is what the Lua script prints:

W0422 07:19:24.045719 LuaContext.cpp:93] Lua says: table
W0422 07:19:24.045749 LuaContext.cpp:93] Lua says: [RequestOrigin], string, RestApi
W0422 07:19:24.045760 LuaContext.cpp:93] Lua says: [Username], string, alice
W0422 07:19:24.045768 LuaContext.cpp:93] Lua says: [RemoteIp], string, 127.0.0.1

Conclusion: You have access to the username “alice”, as well as to the originating IP address. As far as I understand, this is the information you need: You can tune the routing process given the user that sends the image, similarly to the value of “origin[‘CalledAet’]” that is only applicable to the DICOM protocol.

You’re right! I can just set a different username for each of the peer connections, then use that for the routing after the peer connection. The IP is always 127.0.0.1 since IIS is relaying it, but I also had it stuck in my head that I could only set one username for the laptop side, too much bouncing between the two config.jsons.

Thank you, your comment assisted me greatly.