Automatically delete study only if it exists on another AE

[Ruber van der Linden]

Hi all,

I have two DCM4CHEE instances running.

• PACS A: runs on local network. It has a small storage capacity. Receives the studies from then automatically forward them to PACS B.
• PACS B: runs on a remote place, has a huge storage capacity. Nothing but PACS A sends studies to it. Almost all the studies found on PACS A were exported to it using dcmsnd tool.

So I want PACS A to automatically delete old studies when disk space is running low. But I'm afraid that some studies weren't properly exported to PACS B. What I want is: if PACS A is low on disk space, delete the oldest studies but only after checking if they exist on PACS B.

I found DeleteStudyOnlyIfExternalRetrievable on jmx-console, which seems to do this, but I couldn't find how to specify which AE should be queried before deletion.

Thanks for any help!

[Jon Ander Zuccaro]

Look at this post: https://groups.google.com/forum/#!topic/dcm4che/4WRbgZ3Kpdw

And also this: http://forums.dcm4che.org/jiveforums/message.jspa?messageID=1606

There is an additional step configuring the Storage Commitment part in order to mark your studies as externally retrievable. It is there where you specify the external AE (That should exist as a configured node)

You are on the right track. Run some tests and make sure that the 'ext_retr_aet' column of the study table inside your database is being populated correctly.

[Ruber van der Linden]

Hi,

After reading both threads and the Storage Commitment documentation on DCM4CHEE website, I did (or at least I think I did) the steps to configure storage commitment on both servers.

But I'm still quite lost about how could I test it. I couldn't find where to check the ext_retr_aet attribute. Is there any way to see it on web interface or only on database?

Thanks for your help!

[Ruber van der Linden]

OK, I could find the ext_retr_aet on the database. So far it's null for all studies.

Is there any way to "sync" the data or something like a log that could show stgcmt checks?

Thanks!

[Jon Ander Zuccaro]

Wait, are you talking about old studies having a null value for the ext_retr_aet or new studies that were forwarded to PACS B successfully yet the value remains null after you configured everything?

I don't think ext_retr_aet is going to be populated retroactively for all your old studies only for new ones sent to PACS A and forwarded to PACS B after you apply your changes.

PACS A should send the studies to PACS B, request a Storage Commitment and then the ext_retr_aet value will be populated with the result of this call.

What happens currently if you send a new study to PACS A and it gets forwarded to B?

[Jon Ander Zuccaro]

Ok, I just tested this and it works for me.

Try this configuration:

• Add PACS A as an application entity on PACS B, and PACS B as an application entity on PACS A. You probably have this already.
• Check your forwarding rules on PACS A, but this is probably working already. You should be forwarding to PACS B
  
• On PACS A, go to StgCmtScuScp
• For Calling AETitles, choose ANY
• For RequestStorageCommitFromAETitles, put the AETitle for PACS B
• For TrustStorageCommitFromAETitltes, put ANY
• Go to PACS B this time, and go to StgCmtScuScp
• Make sure the option CallingAETitles is set to ANY

Now, send a new study to PACS A, try to use a test image or something.

Pay attention to the logs on both sites, the study should be Forwarded to PACS B and, and PACS B's log should reflect that PACS B is sending a storage commit response to PACS A, something like this:

    appCtxName:    1.2.840.10008.3.1.1.1/DICOM Application Context Name
    implClass:    1.2.40.0.13.1.1.1
    implVersion:    dcm4che-1.4.31
    calledAET:    PACS A
    callingAET:    PACS B
    maxPDULen:    16352
    asyncOpsWindow:    
    pc-1:    as=1.2.840.10008.1.20.1/Storage Commitment Push Model SOP Class

If this worked, the ext_retr_aet column from the database on PACS A should be filled with the AETitle of PACS B, but only for that new study.