External DICOM Archive for long term storage

[Nicolas Roduit]

I'm trying to use dcm4chee and connect another PACS to consider a gradual data migration.

Referring to this documentation, I can forward the images to another PACS but I don't understand how it works for the Retrieve part. The configuration to be done is already effective.

Would it be possible to do DICOM Q/R on dcm4chee which would answer if it has the series and otherwise would query another PACS? This is to manage the time to migrate all the data to dcm4chee. Or would another strategy be more appropriate?

[Vrinda Nayak]

- Would it be possible to do DICOM Q/R on dcm4chee which would answer if it has the series and otherwise would query another PACS?

Assuming this another PACS (is the long term archive?), the DICOM Q/R  on dcm4chee archive shall forward the requests to another PACS (long term archive) only if it doesn't find the study. This another PACS shall store objects to dcm4chee archive (as DCM4CHEE is set as External Retrieve AE Destination) and eventually store the objects to the destination specified in original C-Move request.

[Gunter Zeilinger]

We typically use different configurations for the two use cases:

1) dcm4chee-arc as local archive using an external DICOM archive as long term archive

2) dcm4chee-arc running as proxy archive in front of an existing DICOM archive during migration to dcm4chee-arc

In the first case we configure the exporter for forwarding received series to also  request storage commitment from the external archive, and mark instances, which storage was successful committed by the external archive as retrievable  from that "External Retrieve AE". If the local storage is configured as "cache storage", objects of instances so marked as external retrievable will be deleted according configurable deleting criteria (free disk space, study age, least recently received/used, ...). But the instance records stay in the DB. So queries can always be solved locally. For retrieval of no longer local available objects, C-MOVE retrieve requests are forwarded to the external archive, either with unchanged Move Destination - so the external archive directly send the requested objects to the  original Move Destination - or it is changed to the local archive, which will store the received objects (again) locally and forward them to the original Move Destination.

s.o. https://github.com/dcm4che/dcm4chee-arc-light/wiki/External-DICOM-Archive-for-long-term-storage

In the second case, the local archive is not aware of the content of the external archive, so C-FIND RQs have to be also forwarded to the external archive and the responses are merged with local matches according configurable strategies and sent back to the C-FIND SCU. And if there are no local DB records for an entity requested by a C-MOVE RQ, the C-MOVE RQ is forwarded to a configured "FallbackMoveSCP", either with the unchanged Move Destination, or with the local archive as Move Destination, and acting as in the previous use case.

s.o.

https://github.com/dcm4che/dcm4chee-arc-light/wiki/Proxy-query-requests-to-another-Archive

https://github.com/dcm4che/dcm4chee-arc-light/wiki/Proxy-retrieve-requests-to-another-Archive

There is currently no corresponding forwarding of QIDO/WADO-RS implemented - beside redirect of WADO-URI to a configured fallback WADO-URI Web Application.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

--

You received this message because you are subscribed to the Google Groups "dcm4che" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/e126c442-7482-4464-8d04-52786a8024e0%40googlegroups.com.

[Nicolas Roduit]

Thanks, that makes it a lot clearer.

On Friday, April 24, 2020 at 3:05:50 PM UTC+2, gunterze wrote:

We typically use different configurations for the two use cases:

1) dcm4chee-arc as local archive using an external DICOM archive as long term archive

2) dcm4chee-arc running as proxy archive in front of an existing DICOM archive during migration to dcm4chee-arc

In the first case we configure the exporter for forwarding received series to also  request storage commitment from the external archive, and mark instances, which storage was successful committed by the external archive as retrievable  from that "External Retrieve AE". If the local storage is configured as "cache storage", objects of instances so marked as external retrievable will be deleted according configurable deleting criteria (free disk space, study age, least recently received/used, ...). But the instance records stay in the DB. So queries can always be solved locally. For retrieval of no longer local available objects, C-MOVE retrieve requests are forwarded to the external archive, either with unchanged Move Destination - so the external archive directly send the requested objects to the  original Move Destination - or it is changed to the local archive, which will store the received objects (again) locally and forward them to the original Move Destination.

s.o. https://github.com/dcm4che/dcm4chee-arc-light/wiki/External-DICOM-Archive-for-long-term-storage

In the second case, the local archive is not aware of the content of the external archive, so C-FIND RQs have to be also forwarded to the external archive and the responses are merged with local matches according configurable strategies and sent back to the C-FIND SCU. And if there are no local DB records for an entity requested by a C-MOVE RQ, the C-MOVE RQ is forwarded to a configured "FallbackMoveSCP", either with the unchanged Move Destination, or with the local archive as Move Destination, and acting as in the previous use case.

s.o.

https://github.com/dcm4che/dcm4chee-arc-light/wiki/Proxy-query-requests-to-another-Archive

https://github.com/dcm4che/dcm4chee-arc-light/wiki/Proxy-retrieve-requests-to-another-Archive

There is currently no corresponding forwarding of QIDO/WADO-RS implemented - beside redirect of WADO-URI to a configured fallback WADO-URI Web Application.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[zea...@gmail.com]

Hi Gunter,

I have a question about the first configuration. We configured it like you said.

Now, when we receive data from the external archive to the lodal archive , do we need to send the data back to the external archive so that it is marked as external retrievable. 

Or is there another way to mark them as external directly when storing them? 

In dcm4chee2 there was a function called 'StgCmtScuBySeriesStored'.  (DICOM Storage Commitment SCU requesting storage commitment for objects received from specific AETs.

Use case: Request Storage Commit (and set external retrieve AET in consequence) for objects received from central archive without need to forward the objects back to central archive. (Migration, Prefetching, ..))

Is this alo possible, or is there another way?

To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.

[Gunter Zeilinger]

s. RESTful services STGCMT-RS - Request Storage Commitment from external Archive , which can be also triggered for individual or matching entities from the UI.

[Furkan]

Hello,

This RESTful service (or triggered on UI) doesn't mark the study as external retrievable (doesn't update the ext_retrieve_aet field on DB). 

if we set Storage Commitment SCP AET on exporter description then the study is marked as external retrievable. isn't it?

24 Eylül 2021 Cuma tarihinde saat 15:30:49 UTC+3 itibarıyla gunt...@protonmail.com şunları yazdı:

[zea...@gmail.com]

Is it possible to configure an export rule for this use case? To trigger to request Storage Commitment from external Archive without sending the studies back?