Include more than one DIMSE sources

knopkem / dicomweb-proxy

A proxy to translate between dicomweb and traditional dicom dimse services (PACS communication)

Other

71 stars 20 forks source link

Include more than one DIMSE sources #56

Closed albertosaez closed 2 years ago

albertosaez commented 2 years ago

How could be possible to include more than one DIMSE sources ?

The idea is that the proxy allow to search across different Q/R DICOM nodes, and answers back the first match.

knopkem commented 2 years ago

While currently not possible, this is rather trivial to implement. There are then two ways of representing the result. a) merged results from all sources (this should merge studies/series of the same patient across multiple sources. This becomes a challenge if the patient id is different b) group by AET - all results are split, no merge needed. Workflow wise approach a) is usually nicer - as the user usually doesn't care about the source b) is cleaner from a technical standpoint. I'll try to implement this, as it's a nice extension (and I've done this in the past already)

albertosaez commented 2 years ago

I'm glad you find it interesting.

As this is a "proxy" I think the ideal woluld be (a), but allwasy respecting the PatiendID + PatientID issuer.

But how you plan to deal with multiple machings ? What do do when a match is present in more than one source-repository ?

In my specific scenario, we have a "legacy repository (> 4 years old studies)" and a fresh one, if searching for a patient you could find resutls (even the same studies) in both respositories. Which one to return ? the first one ? The one with more intances ? ....

knopkem commented 2 years ago

It's indeed a bit trickier than I thought as the choice of AET cannot be controlled (the proxy doesn't control the client). However this is how I plan to do it:

sources have priority e.g. by order (in case of duplication, first in list is the source)
in case patient data or even study data (e.g. study1/series1 on AET1, study1/series2 on AET2) is split on multiple AETs then the result is merged in the QIDO request
When retrieving series 1 and series 2 (from above sample) C-Get/Move will try to find it first (basically iterating the list until a match was found -- this is to avoid state. It's a bit slower of course but probably not much, let's see
mixed series are not supported (e.g. study1/series1 on AET1 has 100 images, study1/series1 on AET2 has 120 images), here the first one is taken. This case is very unusual anyway

Let me know if you see any Problems with this or if it doesn't fit your use-case Cheers

albertosaez commented 2 years ago

I think it's an excelent strategy. Very complete, and by sure it will fit this use-case.

knopkem commented 2 years ago

Hi @albertosaez, I pushed a new version 1.4.0 that includes merging of multiple peers. Note that the default.config has changed, notably config.target become config.peers which now expect an array of nodes. Normal use with one peer should not behave different to before, while having multiple peers will be a bit slower as it:

needs to wait for all C-FIND requests to complete before showing results (so the slowest PACS defines your speed)
needs to iterate over each PACS when requesting data (this is sequential but shouldn't take too long) Let me know if you discover any issues. Merry X-mas

albertosaez commented 2 years ago

Brutal ! Great news. Thanks,. I'll start testing it asap !

And Merry X-mas!!